What is considered the complete software medical device?

SSchoepel

Involved In Discussions
#1
Curious what different companies consider the final medical device for SaMD.

For medical software that runs in a client-server environment there is a client executable that runs in Windows and is given to the customer as the executable. The server software is a set of .war files (java executables). These executable files are designed and tested to run against recommended (free) server OS-level software that are defined in the manual (like Apache Tomcat).

As a convenience for install, Customer support creates a server image file with the medical device .war files and the free server software. Just installing the free supporting software would not allow the device to run and while recommended, that free software is not the only OS-level software that could run the .war files. The free software recommended and put into the server image file is not modified in any way from it's released version by those manufacturers.

Customer Support performs the installation and configuration which may or may not include set up of the free OS-level software that was not created or modified. Customers may have a server with all the software (except for the .war files) already.

Which would be considered the actual medical device on the server side (or is there another scenario):
1. the .war files that contain the things we designed and released for use with the client
2. the server image with the .war files and the free software OS-level files

Is there a guidance document from any source on this?

Thank you
 

yodon

Trusted Information Resource
Involved in Discussions
#2
Well rats... my brilliant initial response got lost in a vBulletin error (oddly, that seems interestingly appropriate). Trying again...

I do think this is an interesting question so thanks for posting and I'm hoping it will trigger a robust discussion. And I'll start.

My take would be that the scope of the SaMD system would exclude Apache Tomcat. Similar argument for not considering Windows a part of the client side application. Similar argument for not considering the browser a part of a web-based application.

That said, I would take plenty of precautions (proportionate to the risk associated with the system failing). If the risk is rather substantial and the Tomcat software could contribute to failure, I would consider limiting execution to a specific version / configuration; i.e., not allowing just any old Tomcat version / configuration. I would have pretty specific requirements for version and configuration. Regardless, I'd probably do a level of testing under any version that you want to claim the system can be used with. (Similar to checking out the client side application under a variety of Windows versions). I would also address this in my Risk File (probably looking a bit more closely at configuration options). Finally, I would suggest that a monitoring program (similar to what you would do for SOUP) be established to check out new releases of Tomcat and do testing to ensure compatibility.
 

SSchoepel

Involved In Discussions
#4
Thank you for the quick response. That's what I was hoping to hear and leaning toward but want to make sure that there isn't some assumption or guidance that the product is more than the actual set of files that contain the product features.

We do most of what you mentioned, so I'll be checking what we need to do to show it is fully considered and recorded.

I hadn't thought of monitoring the performance/status/configuration issues with just those free items themselves, only when there was some relation to how our product is running. I will have to ponder that with customer support.
 

BhupinderSinghPawa

Involved In Discussions
#5
For the client side, the Software System would constitute of the client executable and underlying Windows OS. The Windows OS to be treated as SOUP. The upgrades, patches and obsolescence of SOUP to be implemented. The Risk Management to consider failure or unexpected results from SOUP and the outstanding defects of SOUP. This is with EN 62304 compliance required for EU MDD. The software safety classification of the SOUP item to be done.

Similarly, for the server side SaMD, the software system by same principles consists of the server software (.war), Apache Tomcat server and the underlying OS (whether windows / Linux / Unix variants). The Apache and OS will be SOUP and to be addressed by SOUP requirements if you are following 62304.

Network security and access control also should be addressed.
 

yodon

Trusted Information Resource
Involved in Discussions
#6
For the client side, the Software System would constitute of the client executable and underlying Windows OS. The Windows OS to be treated as SOUP.
Hmm... I would disagree with treating the OS as SOUP. Certainly, and to an extent commensurate with the risk of the software (failing), risks with the OS and known issues could be considered. But how would you, for example, specify functional and performance requirements of the OS? I also don't see it very practical to analyze changes to the OS. I think you'd be endlessly chasing your tail trying to do so.

If you do go down that rabbit hole, where do you stop? Are all the device drivers also SOUP? All the services running?

We've never called out the OS as SOUP and have never gotten any push-back. Our approach is to identify (and test against) specific OS versions (including patch levels sometimes). Depending on the safety classification, we may tighten the controls regarding which OSs the software can run under.

For SOUP, we pretty much draw the line at whatever is included in the binaries of the application; i.e., whatever we install. This typically always includes the libraries provided by the compiler / development tools.
 

SSchoepel

Involved In Discussions
#7
I would have to agree with Yodon that you would end up considering everything on any possible user's computer in risk and as SOUP. For products that are software-only it would be impossible to test against every configuration possible in an OS and every combination of drivers or third-party applications.

Considering the implications of the SaMD not working with the OS features on which the SaMD depends seems appropriate and has been considered and, of course, testing against the OSs/versions of OSs that the SaMD is supposed to run against.

The delineation of drawing the line at what is included within the binaries of the SaMD seems appropriate.
 
Top