IEC 62304 Risk Classification - With and without hardware control

DanMann

Starting to get Involved
#1
Apologies if this has been asked before, I did look through the threads, but could not find an answer.

My company makes (IVD) medical devices. One instrument we are designing has a heated section where samples are stored. If the heated section gets too hot, then the samples are damaged and the patient could be misdiagnosed (false negative).

The intent is that the temperature in the heated section is controlled by the user entering a target temperature and some software reading a thermistor in the section and turning a heater on or off to aim for the target temperature.

We would also have an electronics/hardware (not software) control to ensure the software is working correctly - I believe the intent is a comparison circuit; I'm assuming we can verify this hardware aspect such that this would give us an acceptable risk.

Without the hardware control, we would classify this as a Class C software item.

With the verified hardware control, how would we classify this? 4.3 suggests it would be a B, but B.4.3 suggests it would be an A as the risk can be assessed after the hardware (which controls the risk) is added.
 
Elsmar Forum Sponsor

Tidge

Quite Involved in Discussions
#2
I am led to believe that this would never be a Class C software. A misdiagnosis certainly could certainly lead to an extremely severe outcome for a patient, but unless the diagnostic device is somehow directly controlling therapy delivered to the patient (or otherwise being the sole arbiter of a therapy) I don't see how this level of harm is possible. Kudos to you if your device has become so critical to care! I suppose you can reach class C if somehow the temperature related hazard can severely harm an operator, but I doubt this is how class C is part of the conversation.

With that out of the way, I don't recommend trying to land on class A because you believe you might actually have a non-software risk control that can 'take over' if the software fails. Keep in mind that the FDA's Software Safety Classification also has 3 levels of concern (major, moderate, minor) roughly commensurate with the 62304 classification schemes, but the FDA explicitly does not allow for an a priori consideration of risk controls to reduce the classification of software. I think this is one case where the FDA got it right, and 62304 is overthinking this issue from the wrong direction. If I wanted to entertain the notion that 62304 is correct that external risk control measure can be implemented such that the classification is reduced (and specific 62304-development efforts are not value-added), I would have to see a complete analysis of the system (including development and testing) without software to demonstrate that any identified external risk controls are effective in the absence of software before I would believe that the software system really hasn't been allocated any necessary risk controls. This is not practical for a majority of ME device development, as software and hardware are generally developed in parallel.

The difference between a 62304 class A and class B software primarily come down to the nature of the development deliverables and the requisite amount of work that goes into those deliverables. If you start a project knowing you have class A, a project can save some effort by reducing the amount of necessary deliverables. The FDA will still require the deliverables for software with a classification of moderate which may not be on hand if the software was developed as class A. It has been my experience that (even setting aside the FDA requirements) more effort is required to rationalize the reduction of the entire software system from class B (assuming no risk controls external to software) to class A than can be saved by just treating it as class B.

Now specific to the system you describe, with my assumption that prior to decompositon (of software safety elements) that the software system is class B (classification = moderate). If the thermistor cut-out circuit is a back-up for the software-controlled oven control, then the software is clearly controlling the temperature and it should be treated as class B. The development team is certainly has specific requirements for the software and is doing development work, testing the code and is open to the idea of modifying the code for optimization and bug fixes. For class B, the risk lines that discuss this feature of the software are going to reference the requirements, elements of the software architecture and the assorted testing specific to this feature. These risk lines will also include an additional link to the hardware element providing an additional backup.

If you believe the software is class A (and somehow rationalize it as a minor classification per FDA) your risk lines should identify the thermistor as having the primary responsibility for the temperature profiles and also as being the primary risk control. Don't waste any development effort on the software (for this function) as whatever the team throws together won't need to really work as the thermistor is doing everything. If you actually believe this (class A) the project shouldn't be wasting resources on the software development.

One final word of caution for these specific design choices. No matter which way you go (thermistor is primary, software is primary) you have described a system which potentially has two 'bosses' and can lead to arbitration conflicts. This circumstance ought to be explicitly called out in the risk files with an appropriate level of analysis to guarantee that any such risks are acceptable.
 

yodon

Staff member
Super Moderator
#3
@Tidge gave a great reply. Only thing I would add is that most reviewers are not software-savvy and don't handle the lower-the-risk-by-external-controls thing well. They consider the software / firmware pretty much in lock step with the device risk level. Sure, you can fight it, but, that may lead to LONG delays in getting clearance (if ever). By and large, I believe most of the Class B stuff is generally good software development practices anyway and overall beneficial in the long run.
 
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
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
S IEC 62304 software costs and time Medical Device and FDA Regulations and Standards News 2
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 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 5
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
B Our NB says that IEC 62304 is an ISO 14971 Requirement ISO 14971 - Medical Device Risk Management 1
B Clarification on interpretation of some EN ISO 14971:2012 & IEC 62304:2006 req's ISO 14971 - Medical Device Risk Management 46
H ISO 14971 vs. IEC 62304 vs. 98/79/EC vs. ISO 13485 (Software Medical Device) ISO 14971 - Medical Device Risk Management 1
D A desperate call for help - IEC 62304 software IEC 62304 - Medical Device Software Life Cycle Processes 5
B IEC 62304:2006/AMD1:2015 Changes for Class A Software IEC 62304 - Medical Device Software Life Cycle Processes 3
M IEC 62304, ISO 14971 and FDA Medical Device SW Guidance 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 5
K IEC 62304 - Compliance steps IEC 62304 - Medical Device Software Life Cycle Processes 5
K ISO 14971 and IEC 62304 - Medical Device Software House ISO 14971 - Medical Device Risk Management 9
S Software Test Report including IEC 62304 classification IEC 62304 - Medical Device Software Life Cycle Processes 4

Similar threads

Top Bottom