Safety Classification in Medical Device Standalone Software

T

theinonen

#1
Hi,

I feel a little inconvenient when thinking the safety classification. According to IEC 62304 the safety classification may be reduced (C->B, B->A) only by a hardware risk control measure.

In case of really huge standalone software systems (where medical device is the software) there really are no way or point to isolate hazardous software units. For example if the software uses database, every function can be used to manipulate database. "You can code what ever you want where ever you want". The whole software is hazardous because of chance of programming errors.

Using ISO 14971 becomes inconsequential because there is no way to reduce the safety classification. It's good to perform risk analysis but impossible to do risk control. Doing risk control to software by software only increase the amount of software. So there is a point in 62304 that safety classification may be reduced only by a hardware risk control measure. Of course it's important to keep in mind the possible hazards relating to software system..

Safety classification is anyway one of the most important aspects of 62304 and hence affects software development process. Also 5.5.4 specify lots of documentation for each software unit.

Does anyone have some experience concerning standalone software and safety classification?
 
Elsmar Forum Sponsor

Marcelo

Inactive Registered Visitor
#2
Hum, i really didn´t understand some of your points.

According to IEC 62304 the safety classification may be reduced (C->B, B->A) only by a hardware risk control measu
Where is it?

Using ISO 14971 becomes inconsequential because there is no way to reduce the safety classification
The safety classification is not related directly to risk management. it´s related to the amoount of control youhave to perform (requirements of the standard) during your development lifecycle.

So there is a point in 62304 that safety classification may be reduced only by a hardware risk control measure.
Again, where?

For example if the software uses database, every function can be used to manipulate database. "You can code what ever you want where ever you want". The whole software is hazardous because of chance of programming errors.
Only if every function can lead to injury, you would need to perform an evaluation to ensure that. Anyway, as i said above, this would only determine the amount of control yoou would need to exert.
 
Last edited:
T

theinonen

#3
The safety classification is not related directly to risk management. it´s related to the amoount of control youhave to perform (requirements of the standard) during your development lifecycle.
That is true. And in case of really huge software it needs a lot of documentation.


It can be found from 4.3 software safety classification. "-- from a software failure is subsequently reduced to an acceptable level (as defined by ISO 14971) by a hardware risk control measure -- software safety classification may be reduced from C to B --". As I understand it there is no other way to reduce classification for software unit.



Only if every function can lead to injury, you would need to perform an evaluation to ensure that. Anyway, as i said above, this would only determine the amount of control yoou would need to exert.
That was my point. I mean can you really isolate some functions and be sure that there are no errors in code? What is acceptable rationale for some function to be A class if there is a possibility that someone code there some error that leads to injury even if there shouldn't be nothing leading to injury according to specification. It is in the end all about testing that everything is as specified. But if it's so then there is no possibility that any function can lead to injury. Because everything is tested and it works.

The problem is that software still can lead to injury or death if there is done some coding error somewhere. And that is why the software should be class C. And in standalone software there is no possibility to do hardware risk control.

But I'm not sure about my rationale if it is correct. I think the standard is intended for embedded systems that contains both hardware and software, not for information systems.
 

Marcelo

Inactive Registered Visitor
#4
It can be found from 4.3 software safety classification. "-- from a software failure is subsequently reduced to an acceptable level (as defined by ISO 14971) by a hardware risk control measure -- software safety classification may be reduced from C to B --". As I understand it there is no other way to reduce classification for software unit.
I think you might have missed the beginning of the phrase:

If the RISK of death or SERIOUS INJURY arising from a software failure is subsequently reduced to an acceptable level (as defined by ISO 14971) by a hardware RISK CONTROL measure, either...
So no, hardware is not the only option of risk reduction.

This is also clear from the note one 7.2.1 - NOTE The RISK CONTROL measures can be implemented in hardware, software, the working environment or user instruction.


The problem is that software still can lead to injury or death if there is done some coding error somewhere. And that is why the software should be class C. And in standalone software there is no possibility to do hardware risk control.
That´s why you have to control the development lifecycle, tests should ensure that coding error are corrected before release.

But I'm not sure about my rationale if it is correct. I think the standard is intended for embedded systems that contains both hardware and software, not for information systems.
No, the standard is intented both to embedded software and stand alone as it´s a development lifecycle standard. In fact, the standard is nothgin more than general knowledge from the software engineering field which in general applies to all software, plus some concerns of the medical device industry.

Anyway, safety requirements for stand alone software are not taken into consideration (in the case of medical electrical equipment, safety requirements can be found in IEC 60601-1). In the case of standa-alone medical device software, a new standards is being developed (IEC 82304-1 Ed. 1.0 - Healthcare Software Systems - Part 1: General requirements) which will address safety requirements.
 
Last edited:

Peter Selvey

Staff member
Super Moderator
#5
I believe the issues raised by "theinonen" is valid mistake in the standard that will likely be fixed in the future.

The standard explicitly refers only to a "hardware risk control" when determining classification, whereas in practice protection systems are often a combination of hardware and software, and could also be purely software. Provided such a protection system is reasonably isolated from the control system (including in the case of software, separation of data and algorithms), a reduction in software classification is justified.

For example, a dialysis system temperature control will normally be handled by one system containing hardware and software, while the protection relies on an independent system with separate hardware and software. One would reasonably expect that having implemented a fully independent system, the software for both control and protection can be reduced to Class B, rather than Class C.

However, according to IEC 62304 this is not allowed as the protection system also contains software.
 
K

kasrt

#6
I was searching this forum for some guidance on tracing from software item to it's cause when i chanced upon this topic. Interesting was a reply from mmantunes wherein he mentioned that "The safety classification is not related directly to risk management. it´s related to the amoount of control youhave to perform (requirements of the standard) during your development lifecycle."

Isn't the safety classification for the software item (identified as hazardous), the result of the 'Severity' rating explained in ISO 14971? I would think they are directly related? For e.g. Severity as 'Catastrophical' or 'Critical' would probably be rated as class C...

My second query however which i also choose to post it in this topic is, can someone point me to an implementation solution wherein they have traced successfully from software item to cause. Or is there a way wherein we can trace from software item to risk control measure, bypassing the cause?
 

Peter Selvey

Staff member
Super Moderator
#7
The point that mmantunes is saying is that ISO 14971 risk management is about deciding whether risk control measures are necessary, whereas classification in IEC 62304 simply decides whether additional design controls (procedures, records) are necessary. The key difference is that ISO 14971 risk controls apply to the medical device, while IEC 62304 design controls apply to the manufacturer.

Of course they are related but then everything about a medical device is somehow related to risk.

Tracing from software item to cause: I believe the point of view of the standard is to assume that a particular software item (module) has a software bug and then see what the impact is. In other words, a 100% assumption that the software module fails.

If this has a significant outcome, then you have two basic options: one is to put more effort into design specifications, unit breakdown, unit testing, integration and system testing (reduce the chance of a software bug); the other option would be to add a separate protection system which may be software, hardware, mechanical or even simply reducing the source of risk (inherent protection). Very much a case by case situation.
 
K

kasrt

#8
Thanks Peter!

But im still unclear regarding my query, whether a software item (identified as hazardous) needs to trace to its cause. 62304 section 7.3.3 asks specifically to trace from software item to the specific software cause.

From what i understand from your reply, tracing from software item to risk control measure and to the implementation of the risk control measure is sufficient. Is that what you meant? Will this tracing help me to explain to my external auditor for 62304, clause 7.3.3?
 

Peter Selvey

Staff member
Super Moderator
#9
It's a good question, so this is just my opinion:

It only applies when there is a specific risk control measure (protection system) to cover for failures in software.

For lower risk devices, this may be a rare case or limited to simple checksums and the like (see examples below).

For high risk devices, in most cases the the complete system (including hardware and software) will simply be considered broadly to fail, requiring a separate system for protection.

In my case I designed software driven equipment for testing ECGs (it's not itself medical but useful for example). Controlled by a PC, it has a USB module that sets up special ECG testing circuits and streams waveform data to a medical ECG. The following is a couple of examples of application of 7.3.3.

Example #1: A lost data packet in USB communication is a serious concern, especially since the packets may be too small to see on the ECG's screen, thus it may result in invalid testing without the user being aware. This is caused by the PC being too busy with other tasks. The "risk control measure" is a counter system to check if there are any missing packets in the streaming data.

So for 7.3.3:
Hazardous situation: lost data packet(s) resulting in an undetected invalid test
Software item: "SendNextDataPacket"
Software cause: PC unable to respond to interrupt request
Risk control: Add SequenceCheck counter byte
Verification: Tests with special button to corrupt SequenceCheck

Example #2: In some cases the waveform data is the result of many calculations (ECG profile + mains noise + pacing overshoots), and the total data point may exceed the mV range. The range is selected only based on the main waveform. There are two risk controls for this: a general range limit check; and limitation of ECG profile to 2.5mV range when pacing mode is selected.

7.3.3
Hazardous situation: waveform data out of range (clipping of output)
Software item: "CalculateWaveformData"
Software cause: Addition of sub-waveforms (pacing overshoot, mains noise) results in overrange;
Risk control: #1 limit ECG profile to 2.5mV during pacing mode; #2 Add range check just before final packet assembly;
Verification: #1 Attempt to set above 2.5mV for ECG during pacing; #2 Tests with deliberate errors

Now, you are probably wondering at what point is something a risk control measure and what is just normal defensive programming. There is no clear cut rule; adding documentation has both good and bad points, ideally documentation should only be used if there is a net benefit. It is not unreasonable to start out to document a fixed number of risk control measures against software failures (e.g 2-5 for a low risk device); then select the most significant risk controls and document only these. As time goes by you will get a feel for benefits/disadvantages and either shorten or increase the number included in this list.
 

Marcelo

Inactive Registered Visitor
#10
I believe the issues raised by "theinonen" is valid mistake in the standard that will likely be fixed in the future.

The standard explicitly refers only to a "hardware risk control" when determining classification, whereas in practice protection systems are often a combination of hardware and software, and could also be purely software. Provided such a protection system is reasonably isolated from the control system (including in the case of software, separation of data and algorithms), a reduction in software classification is justified.

For example, a dialysis system temperature control will normally be handled by one system containing hardware and software, while the protection relies on an independent system with separate hardware and software. One would reasonably expect that having implemented a fully independent system, the software for both control and protection can be reduced to Class B, rather than Class C.

However, according to IEC 62304 this is not allowed as the protection system also contains software./QUOTE]

Hello Peter, and sorry for the late reply to this discussion (i've missed something at some point in time :))

I do not think there's a problem with the standard, but this might be due interpretation.

When a separate software is used as a risk control measure (protection system), it goes into

The MANUFACTURER shall assign to each SOFTWARE SYSTEM that contributes to the implementation of a RISK CONTROL measure a software safety class based on the possible effects of the HAZARD that the RISK CONTROL measure is controlling.
So the safety classification would be the same as the one it's trying to control. So i don't see why a reduction in the risk classification i justified as it would be the same.

The idea behind the standard is the all software is unreliable even as a risk control measure, so only a hardware hazard control measure would justify a reduction in the safety classification (which again, and thanks for your clarification in the other post, is only related to the amount of design control which needs to be applied....so, when we are discussion safety classification degradation, we are meaning only for example less documents to create).
 
Thread starter Similar threads Forum Replies Date
M FDA News USFDA Final Rule – Medical Device Classification Procedures: Incorporating Food and Drug Administration Safety and Innovation Act Procedures Medical Device and FDA Regulations and Standards News 0
A IEC 62304 safety classification, External Controls and off-label use related risks IEC 62304 - Medical Device Software Life Cycle Processes 5
K IEC 62304 Amd 1 2015 - Figure 3 – Assigning Software Safety Classification IEC 62304 - Medical Device Software Life Cycle Processes 11
O Safety Classification and Reasonably Foreseeable Misuse IEC 62304 - Medical Device Software Life Cycle Processes 3
M Level of Concern (FDA) vs. Software Safety Classification(IEC) US Food and Drug Administration (FDA) 3
A Canadian Safety Labels for medical electrical equipment Canada Medical Device Regulations 0
A Applicability of Photobiological Safety Evaluation for LED used in medical devices Reliability Analysis - Predictions, Testing and Standards 1
A Should I take an online course for a career in Occupational Health and Safety? Career and Occupation Discussions 2
E 60601-1 - Tilt testing - Tensile safety factor IEC 60601 - Medical Electrical Equipment Safety Standards Series 1
Marc ISO 26262- Road vehicles – Functional safety ISO 26262 - Road vehicles – Functional safety 0
A Defining a lower ESD test level in IEC 60601 safety test IEC 60601 - Medical Electrical Equipment Safety Standards Series 5
D Safety data sheets software REACH and RoHS Conversations 2
M ECG lead leakage currents - How to specify ECG leads during electrical safety testing IEC 60601 - Medical Electrical Equipment Safety Standards Series 5
R Quality System Functional Safety Checklist / Guidance IATF 16949 - Automotive Quality Systems Standard 0
N German National Requirements - Safety Officer/Authorised Rep Other Medical Device Regulations World-Wide 0
C Where to draw the line for "sufficient evidence" to verify safety/performance of a device? CE Marking (Conformité Européene) / CB Scheme 2
A Baby food manufacture - food safety requirements Food Safety - ISO 22000, HACCP (21 CFR 120) 0
dgrainger Informational EU medical device website change from 'Growth' to 'Health and Food Safety' (6/2020) Medical Device and FDA Regulations and Standards News 0
D Safety Assurance Case Report Format ISO 14971 - Medical Device Risk Management 4
B Product Safety Responsibility - Job shop such as a machine shop AS9100, IAQG, NADCAP and Aerospace related Standards and Requirements 10
K Things to learn during lockdown.... Safety-related books/articles/threads Book, Video, Blog and Web Site Reviews and Recommendations 2
JAMESH Job Safety - Lockout/Tagout and Respiratory Protocols Manufacturing and Related Processes 3
J Raw material certificates - CC - Safety products - Sheet metal stamping IATF 16949 - Automotive Quality Systems Standard 1
M Differences in post market safety reporting for Combination Product Applicants Medical Device and FDA Regulations and Standards News 1
S Should safety checks be included in the Control Plan? IATF 16949 - Automotive Quality Systems Standard 5
adir88 Information of safety can reduce risk now? ISO 14971 - Medical Device Risk Management 12
D Is there a specific location for PPE such as safety glass holders and glove dispensers should be mounted Occupational Health & Safety Management Standards 10
M Do you need an Applicable general safety and performance requirements Checklist? EU Medical Device Regulations 2
S VW Supplier Product Safety Representative (PSB) upgrade to PSCR VDA Standards - Germany's Automotive Standards 4
J FDA wants electrical safety testing on battery powered medical device US Food and Drug Administration (FDA) 11
T Confirming The Local Safety Regulations for Equipment - I'm in Malaysia General Measurement Device and Calibration Topics 1
MrTetris Unacceptable risk and information for safety ISO 14971 - Medical Device Risk Management 16
A Contraindication Safety Statement in website - Radiotherapy equipment Other Medical Device and Orthopedic Related Topics 1
L External power supplies: How close does the safety report have to match the end-use application? IEC 60601 - Medical Electrical Equipment Safety Standards Series 4
C Safety lettering on a product CE Marking (Conformité Européene) / CB Scheme 5
M EU – Chemical Safety Report – CSR – REACH Authorisation decisions – Triton X-100 – Ortho-clinical-Use1 REACH and RoHS Conversations 0
M Informational EU – Minutes of the 24 July 2019 SCHEER Working Group on safety of breast implants in relation to anaplastic large cell lymphoma (BIA-ALCL) meeting Medical Device and FDA Regulations and Standards News 0
M EMC Directive and product safety standards CE Marking (Conformité Européene) / CB Scheme 1
S Safety Class A with no test? IEC 62304 - Medical Device Software Life Cycle Processes 1
M Informational MDCG 2019-9 Summary of safety and clinical performance A guide for manufacturers and notified bodies – August 2019 Medical Device and FDA Regulations and Standards News 0
D Requirement of Pharmacovigilance (Drug Safety) Risk Based Strategic and Tactical Audit Plan General Auditing Discussions 0
M Informational Several US FDA draft guidances, including some specific device guidances for the Safety and Performance Based Pathway Medical Device and FDA Regulations and Standards News 0
M Informational USFDA final guidance – Safety and Performance Based Pathway Medical Device and FDA Regulations and Standards News 0
M Informational Medical Device Safety Action Plan: Protecting Patients, Promoting Public Health Medical Device and FDA Regulations and Standards News 0
S System safety assesment Federal Aviation Administration (FAA) Standards and Requirements 0
M Informational TGA Consultation: Proposed changes to medical device essential principles for safety and performance Medical Device and FDA Regulations and Standards News 0
rezayatmand IEC 60601-2-18 Medical electrical equipment - Part 2-18: Particular requirements for the basic safety and essential performance of endoscopic equipmen IEC 60601 - Medical Electrical Equipment Safety Standards Series 2
B Evaluation of Basic Safety during EMC Immunity or Climate Testing IEC 60601 - Medical Electrical Equipment Safety Standards Series 0
P Is there a counterpart to the General Safety and Performance Regulations for the USA? Other US Medical Device Regulations 2
M Informational The US FDA is Recommending Transition to Duodenoscopes with Innovative Designs to Enhance Safety: FDA Safety Communication Medical Device and FDA Regulations and Standards News 0

Similar threads

Top Bottom