IEC 62304 - Functional and performance requirements for SOUP items

[KrishQA]

Hello All,

So the 62304 requires us to:

5.3.3) Specify functional and performance requirements of SOUP item
If a SOFTWARE ITEM is identified as SOUP, the MANUFACTURER shall specify functional and performance requirements for the SOUP item that are necessary for its intended use. [Class B, C]

Does this refer to a requirement spec for the SOUP we intend to use, that is documented in the architecture document?

There was another question I posted about SDK being a SOUP and testing it as well. I think it was @Tidge who mentioned that we test an SOUP based on the requirement spec for the SOUP. Is this the section where we document the requirement spec?

TIA

 

[yodon]

We put our SOUP requirements in the Architecture doc. They've always been pretty high-level and, of course, limited to our use (needs) of the SOUP. Honestly, I don't think we've ever explicitly tested to the SOUP requirements (a point that I'm still pondering now). Mostly it's been for some service provision and the service is implicitly tested. Something for me to chew on a bit more.

 

[Tidge]

The architecture is a very natural place to identify SOUP elements. Integration testing leverages the architecture and should be providing sufficient evidence that the SOUP elements are working as necessary.

Something to consider with SOUP: When development is guided by 62304, the (standard's) requirements around an Architecture and Integration Testing typically drive appropriate consideration around questions like "What is the SOUP supposed to do?", "Is this SOUP working?" and "How well is the SOUP controlled?". These types of questions are driven by a risk assessment process (in 62304), but they are so fundamental (to the development process) that there is very little chance of answering those types of question.

For Medical Devices: aside from software, there are not many (any?) other consensus development standards. This makes it "easier" to avoid asking/answering those types of questions. The presumption of adherence to 14971 is that such questions are being asked (and answered) for all components of a medical device, filtered through the lenses of risk assessment. A common pitfall of medical device development in areas other than software is that the risk assessment (I'm particularly thinking about identifying/testing risk controls) can come "too late" in the life-cycle process. I'm my own thoughts are times when supposed "like for like" components (chosen on the basis of datasheets) simply didn't work in a finished design, despite all the best assurances from well-meaning engineers. In those instances, the problem was that the engineers were thinking about what the part was, rather than what the part was doing.