Relying on mitigations implemented in non-medical device

[kopo85]

Currently developing a software medical device locked to deployment on a non-medical, internally developed general computing platform.

The requirements and mitigations are defined and evaluated for the system as a whole, including the non-medical portion. This has lead to mitigations being identified and implemented entirely within the scope of the computing platform (e.g. OS/HW redundancy features needed by the medical device, OS firewall settings, OS notifications....). It is a known/fixed computing platform that the product will be verified/validated on.

I would like to take advantage of this and rely directly on the verification of the mitigations on the computing platform, without relying on additional external mitigations (e.g. to check the firewall settings at installation/runtime), however I keep running into a logic wall of, if it contains the implementation of mitigations, should it be:
- Considered for risk classification within SDLC?
- Required to meet all the documentation rigor of class A/B/C?
- Be considered a medical device?

I'm very open to answers, or even re-thinking the problem as a whole.

/Chris K.

 

[Ronen E]

What is/are the sales configuration(s)?
Are you also selling the computing platform alone? For what intended uses?
Are you supplying the computing platform together with the "SaMD"?
Does "locked to deployment on" mean that the SaMD can't run on any other computing platform?

 

[kopo85]

What is/are the sales configuration(s)?
- Single configuration deployed on defined server hardware with fixed OS.

Are you also selling the computing platform alone? For what intended uses?
- The compute platform is used in other internal products, but not sold externally (yet).

Are you supplying the computing platform together with the "SaMD"?
- Yes.

Does "locked to deployment on" mean that the SaMD can't run on any other computing platform?
- Correctish... the intention is to limit it to a defined platform to reducing risk associated with installation on an unqualified/untested Server/OS. There are no technical limitations that would stop this from functioning equally on a platform such as AWS or other such service.

 

[Ronen E]

What is/are the sales configuration(s)?
- Single configuration deployed on defined server hardware with fixed OS.

Are you also selling the computing platform alone? For what intended uses?
- The compute platform is used in other internal products, but not sold externally (yet).

Are you supplying the computing platform together with the "SaMD"?
- Yes.

Does "locked to deployment on" mean that the SaMD can't run on any other computing platform?
- Correctish... the intention is to limit it to a defined platform to reducing risk associated with installation on an unqualified/untested Server/OS. There are no technical limitations that would stop this from functioning equally on a platform such as AWS or other such service.

It sounds like your device is not a SaMD. It is the HW+SW combination you provide.

 

[kopo85]

Are you asserting that the HW and OS are part of the medical device?

Assuming you this, then I assume the classification would then pull in full 62304 compliance for the computing platform?

 

[Ronen E]

Are you asserting that the HW and OS are part of the medical device?

Assuming you this, then I assume the classification would then pull in full 62304 compliance for the computing platform?

I am asserting that the way you describe it, from a regulatory standpoint the HW+OS+SW application are a single Medical Device.

I'm not a 62304 expert so can't answer your question directly, but I think that if your medical device includes a computing platform that you've developed you need to validate that computing platform to a certain extent.