Safety Classification in Medical Device Standalone Software

Marcelo

Inactive Registered Visitor
#11
Just forgot to mention one thing....IEC 62304 is at the initial review stage right now so it might be interesting if you could manage to put this and other opinions thru your NC.
 
Elsmar Forum Sponsor

Peter Selvey

Staff member
Moderator
#12
I understand the point of view of the standard: assume software is unreliable and then decide on the level of design controls based the severity of the outcome.

Again to use the dialysis system example: they will normal use two independent systems for control and protection, each having both hardware and software components. The work required for Class C is quite large, in particular Clause 5.4.4 probably triples the amount of work per software unit. So this is not a simple case of just a few more pages of documentation, we may be talking about 1000's of pages for a dialysis system.

The fact that two independent systems are used should allow the manufacturer to drop the classification down to Class B for each system (protection and control). Class B is still a lot of work.
 
Last edited:
K

kasrt

#13
Thanks Peter and mmantunes for the detailed reply!

Was there a tool you used for tracing from software item to cause to risk control?

For implementing clause 7.3.3, one would need to define a hazard id to represent the hazard/harm, a software item id to represent the software item, a cause id to represent the specific software cause, a risk control measure id for representing the measures (mitigation) taken and also a requirement id, since most probably it will be mapped to a requirement within software as well.

software item and it's cause are additional requirements for tracing when compared to 14971.Again a hazard (related to software) can have multiple causes, which in turn can have 1 or multiple mitigations.

Is there a structure you came up with to handle the above?
 
A

andreasm

#14
Hi,
I have a related question concerning the safety classification for medical software. The company I am currently performing my master thesis at is developing a software for a prosthetic device. The software will be present inside a PC as well as the prosthetic and the two will occasionally share data through a plug connection to update data in the prosthetic.
Is it still possible to claim that the software items present in them are segregated enough to give them separate classification?
Secondly, the potential harm presented to the patient by the software is ultimately mitigated by user instructions. Is that a valid "risk control" to use for down grading the classification from a grade B to a grade A?
The only harm caused to the patient would be that the prosthetic would invoke an action contrary to the patients intent. (clutching of hand instead of opening etc)
Thirdly, is there a "default" safety classification for medical databases? I have not been able to find any references to such but figured that here would be the place to ask.

Thank you for your help
Regards,
Andreas
 

glork98

Involved In Discussions
#15
I'll take a shot at two.
Is it still possible to claim that the software items present in them are segregated enough to give them separate classification?
Yes. And the physical separation makes this easier to identify. You do have to consider the effects of what the PC can do through operator misuse and technical failures. As examples, can the user select incompatible options or select harmful configuration values?

Secondly, the potential harm presented to the patient by the software is ultimately mitigated by user instructions. Is that a valid "risk control" to use for down grading the classification from a grade B to a grade A?
That's not the way it works. The software is classified by the largest risk prior to mitigation. This imposes the quality practices. If the risk analysis says that the software component can never, ever cause physical injury or treatment failure no matter how egregious its failure prior to mitigation, then you're Class A. If you don't have everything mitigated down to a low ranking you can't ship the product.
 
A

andreasm

#16
Thanks for the reply glork. That reassured me concerning the segregation :)

Concerning the second question, in accordance with clause 4.3a)


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 by reducing the consequences of the failure or by reducing the probability of death or SERIOUS INJURY arising from that failure, the software safety classification may be reduced from C to B; and if the RISK of non-SERIOUS INJURY arising from a software failure is similarly reduced to an acceptable level by a hardware RISK CONTROL measure, the software safety classification may be reduced from B to A.

it would be possible to reduce the initial software classification from B to A, or C to B, as long as sufficient level of risk control and mitigation has been implemented.
And then, in clause 7.2.1 it says​

The
RISK CONTROL measures can be implemented in hardware, software, the working environment or user instruction.


which makes me wonder if implementing user instructions as mitigating factor against a possible risk would count towards software classification reduction, or can that only be done through hardware?

Thank you :)
 
C

coezbek

#17
I would like to append another aspect of the security classification into the discussion:

How immediate does the software have to cause the danger?

glork98 argues that if "the software component can never, ever cause physical injury or treatment failure" it is A. But how much influence do we assign to the human user which acts upon information from a system?

Consider an thermometer which uses a LCD display to show the temperature. If a software failure leads to an invalid temperature, then a user/doctor might apply the wrong treatment, leading to the death of the patient.

Now the software in the thermometer can never ever kill/harm anybody (unlike a pacemaker, MRI, CT, or similar), but still 62304 seems to make it necessary to categorize the software as class C.
 
P

PaulGr

#18

which makes me wonder if implementing user instructions as mitigating factor against a possible risk would count towards software classification reduction, or can that only be done through hardware?[/LEFT]
Hi Andreasm, as mentioned before in this thread, the standard is clear: only hardware. And personally, for this clause I would not be able to write a rationale to support a deviation.

In general, if your software has the potential to cause injury to patients or users, it is wiser to focus on 'smart' implementation of class B or C requirements than on reducing the safety class.:rolleyes:

And for your 3th question:
Thirdly, is there a "default" safety classification for medical databases? I have not been able to find any references to such but figured that here would be the place to ask.
In my opinion a default classification would not be possible. Every database is used for a specific intended use and different possible effects on patients and users. Classifications range from no medical device to class C.

@coezbek: in your thermometer example the result of the software is evaluated by a user which has more inputs (skin color, sweating,...) which reduces the possibility on injury and possibly the safety class.
 
C

coezbek

#19
which reduces the possibility on injury and possibly the safety class
Now, this is where it gets interesting. In the risk management view of 14971 a reduction in possibility will lead to a reduction in risk. But in 62304 you are not allowed to do that, because you have to assume 100% occurrence. In a strict view on 62304, the thermometer seems to be a class C product. (and I'd love if anybody disagrees ;-)
 
P

PaulGr

#20
Ok, I start to understand your point. Now let me try to disagree :)

First ISO14971. Assume a sequence of events where the thermometer software gives a wrong reading, the nurse writes a wrong value in the medical file and after a lot of other events the patient dies. Severity is critical, probability of the software failure is assumed 100% but overall probability is (in this example) improbable.

Now IEC62304. Guidance B4.3 indicates that safety classification and ISO14971 risks are not aligned (as explained earlier in this thread). So we need to interpret the word 'possible' from the classification rules in 4.3(a). My interpretation is that death or serious injury is not possible based on the ISO14971 analysis above. Assuming that a sequence of events is possible which results in minor injury, the software would classify as B.

I think the point is that not every remote or improbable sequence of events - with a software item involved - which leads to serious injury or death automatically classifies the software item as C.
 
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
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
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 9100, Nadcap and related Aerospace Standards and Requirements 10
K Things to learn during lockdown.... Safety-related books/articles/threads Book, Video, Blog and Web Site Reviews and Recommendations 1
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 0
J FDA wants electrical safety testing on battery powered medical device US Food and Drug Administration (FDA) 8
T Confirming The Local Safety Regulations for Equipment - I'm in Malaysia General Measurement Device and Calibration Topics 0
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
D Summary of safety and clinical performance in GSPR MDR EU Medical Device Regulations 2
A ISO/TS 22163 Item 5.2.4 Safety policy - Example wanted Other ISO and International Standards and European Regulations 2
M Informational US FDA draft guidance – Testing and Labeling Medical Devices for Safety in the Magnetic Resonance (MR) Environment Medical Device and FDA Regulations and Standards News 0
D Electrical Safety During Medical Device Development IEC 60601 - Medical Electrical Equipment Safety Standards Series 3
M Informational US FDA Final guidance – Postmarketing Safety Reporting for Combination Products Medical Device and FDA Regulations and Standards News 0
M Informational EU draft act – Single-use medical devices – safety and performance requirements for reprocessing Medical Device and FDA Regulations and Standards News 0
M Informational TGA – Advertising health products: Rules about safety claims in advertising Medical Device and FDA Regulations and Standards News 0
M Informational MHRA guidance updated to reflect the mDR – Clinical investigations of medical devices – Biological safety assessment Medical Device and FDA Regulations and Standards News 1
R Material safety data sheet (MSDS) related clause in IATF 16949 manual IATF 16949 - Automotive Quality Systems Standard 17
S Implementing a 45001 Health & Safety standard - Internal audit plan wanted Internal Auditing 1
CPhelan Using clinical trial safety data for evidence for CE marking EU Medical Device Regulations 7
I Functional Safety Analysis/Report Example IEC 60601 - Medical Electrical Equipment Safety Standards Series 3
M Routine testing of medical electrical systems - What specific electrical safety tests should be performed? IEC 60601 - Medical Electrical Equipment Safety Standards Series 5
Similar threads


















































Top Bottom