Software Safety classification for two independent systems in one device

Hello,

I would like to ask you for your opinion about the situation related to Software Safety Classification for medical device.
Let's imagine that medical device powered from 230V, with two independent hardware platforms, including embedded software (for convenience, I have attached the "architecture" of the device).

The first software SWI is the "main" software, and it is responsible for most of the software features of the device".
The second software SWII is software that provides some additional features.

To make things a bit more difficult, let's imagine that additional features (HWII/SWII), were added X years later as an "accessory" and the classification of SWI is "A", and SWII is "B" if we will look at into DFMCA/Top Down, and the advancement level of the features.

How shall this situation be handled according to IEC 62304 Safety Classification?

According to the IEC 62304, Classification shall be assigned for the SOFTWARE SYSTEM. Based on the "architecture" of the device, which I have attached, we have here two independent SOFTWARE SYSTEM's, because they share only Power Supply.

If someone asks what is the Software Safety Classification of this device, what will be the answer?
 

Attachments

  • Software Safety classification for two independent systems in one device
    example.drawio.png
    13.8 KB · Views: 21

yodon

Leader
Super Moderator
If you keep reading in the standard, you'll see:

d) When a SOFTWARE SYSTEM is decomposed into SOFTWARE ITEMS, and when a SOFTWARE ITEM is decomposed into further SOFTWARE ITEMS, such SOFTWARE ITEMS shall inherit the software safety classification of the original SOFTWARE ITEM (or SOFTWARE SYSTEM) unless the MANUFACTURER documents a rationale for classification into a different software safety class (software safety classes assigned according to 4.3 a) replacing “SOFTWARE SYSTEM” with “SOFTWARE ITEM”). Such a rationale shall explain how the new SOFTWARE ITEMS are segregated so that they may be classified separately.

e) The MANUFACTURER shall document the software safety class of each SOFTWARE ITEM if that class is different from the class of the SOFTWARE ITEM from which it was created by decomposition.


So you should be ok managing as different classes as long as you provide sufficient rationale.
 

Tidge

Trusted Information Resource
According to the IEC 62304, Classification shall be assigned for the SOFTWARE SYSTEM. Based on the "architecture" of the device, which I have attached, we have here two independent SOFTWARE SYSTEM's, because they share only Power Supply.

If someone asks what is the Software Safety Classification of this device, what will be the answer?

I believe the strict, true answer (for the scenario in the OP) would be "The SSSC is Class B". (Always reference the "most conservative", here SWII... see sidebar)

Per the decomposition of architecture, not all the deliverables would (have to) exist for all software items.

Sidebar: While it is true that the FDA's "Level of Concern (minor/moderate/major)" / "Documentation Level (basic/enhanced)" don't strictly equate to SSSC (A/B/C) , for all practical purposes minor = basic = A, moderate = enhanced = B, major = enhanced = C. The FDA would almost certainly want to see the enhanced level of documentation for any medical device which includes class B software, so I'd simply get used to describing such a device as "SSSC Class B".
 

FelipeSchneider

Involved In Discussions
I have worked on the development of various devices with different PCBs. One of these devices consisted of three PCBs: one master and two slaves. The slaves were responsible for controlling fans and reading some less critical temperatures.

We categorized the entire system as Class B and documented it accordingly.

Taking the risk of encountering problems later on doesn't justify the money and time saved by creating Class A documentation for SWI A.
 
Top Bottom