Software verification vs. system verification

[Given2Fly]

Hi there,

So in our med device development company, we have an engineering dept within which we have a software development team and a system verification team (amongst others). There has been a share of testing between the software development team and system verification team, but it has not been consistent in that some projects involve the system verification team owning software integration testing (component level) as well as system level and in others integration testing is owned by the SW development team. In an aim to get more consistent, I would like to clarify where the line should be drawn. The V model in 62304 clearly shows "Software Integration & SOFTWARE SYSTEM VERIFICATION". North of that on the model is subsystem and system verification which should naturally be owned by the verification team.
Does it matter who owns component level testing?
I'm conscious the the verification group should remain independent of the development team to ensure objectivity and avoid conflict of interest, so where should they draw the line? in other words, what are the elements of the test that would determine if it should be verified by the verification team (independent from design) or the software development team (owns design).
Any help on this would be much appreciated.

 

[Tidge]

Perhaps an overly-simplistic analogy: Imagine if a medical device manufacturer also has an internal group that designs batteries (or power supplies). In this analogy, the 62304-like team is responsible for all of the testing necessary (commensurate to the risk of functions allocated to the battery/power supply), but when they hand over the battery/power supply to the larger group, that group is responsible for all the testing necessary to demonstrate the greater device is safe (and meats its intended use).

 

[Ed Panek]

Perhaps an overly-simplistic analogy: Imagine if a medical device manufacturer also has an internal group that designs batteries (or power supplies). In this analogy, the 62304-like team is responsible for all of the testing necessary (commensurate to the risk of functions allocated to the battery/power supply), but when they hand over the battery/power supply to the larger group, that group is responsible for all the testing necessary to demonstrate the greater device is safe (and meats its intended use).

That analogy describes our company. We have a part of the company that came from Energizer that makes thin-film batteries. That group is a key supplier of our medical devices. You described our functioning well.

 

[Tidge]

I offer the battery analogy for a few reasons:

• It is easy to imagine either/both batteries or/and software in a medical device
• It is easy to see how either could be fulfilling a function of a medical device (crucial or incidental)
• It should be easy to imagine that the design elements of either could be complicated (or simple), and could be outsourced

As far as I know, there isn't a generally applicable consensus standard (beyond 60601-1) for batteries (in medical devices, either development or performance) like there is for software's development standard 62304, so the analogy isn't as neat as I would like.