Medical device software is defined as software that is intended to be used alone or in combination for a purpose as specified in the definition of a medical device in the MDR or IVDR, regardless of whether the software is independent or driving or influencing the use of a device.
So, let’s talk about the two different options for placing your software on the market, which of course would be relevant to its functionality.
- Software as a Medical Device (SaMD): SaMD is a medical device in its own right. It must have a medical purpose on its own. It acts independently from medical device hardware.
- Software in a Medical Device (SiMD): SiMD is software incorporated into hardware that does not function on its own for a medical purpose or to achieve the device’s intended use. It is an integral component of a device. It is also termed embedded software. It drives the use of typically a (hardware) medical device. And again, it does not perform medical purposes on its own.
The term “standalone software” used in the MDD, is no longer used in the MDR.
Examples of Medical Device Software:
- Cardiac monitoring software
- IVD results interpretation software
- Medical imaging software
- Therapy/treatment planning software such as those for drugs or radio therapies
Examples of Non-Medical Device Software:
- Fitness trackers
- Software that is purely administrative and for record keeping
- Insurance billing or admission software
- Laboratory information systems (LIS) which wouldn’t include specialty models that may be developed that are unknown at this time
- Software that does not meet the definition of a medical device or is not an accessory to a medical device
Software may be qualified as medical device software regardless of its operating location. For example, in the cloud directly on a computer, on a mobile phone, or incorporated into a device as a SiMD.
So there are two very important assessment questions for any software medical device manufacturer to start with. Does the device meet the definition of a Medical Device? So you want to be sure to consult the definitions found in both the MDR and the IVDR. Once you’ve moved past that question and answered “yes” to that question, ask yourself, is the device regulated under the MDR or the IVDR? and of course, this is incorporated into its intended use and its functionalities.
There are 10 implementing rules in the IVDR, which can be found in Annex 8, all are important, but the key implementing rules for software include application of the classification rules shall be governed by the intended purpose. If the device in question is intended to be used in combination with another device, the classification rules shall apply separately to each of the devices. Software which drives a device or influences the use of the device shall fall within the same class of the device. If the software is independent of any other device, it should be classified in its own right. If several classification rules apply to the same device, the rule resulting in a higher classification shall apply.
The MDR implementing rules can also be found in Annex 8 chapter 2. Application of the classification rules shall be governed by the intended purpose of the devices. Software, which drives or influences the use of a device, shall fall within the same class as the device. If the software is independent of any other device, it shall be classified in its own right. So, there’s your SaMD. If several rules, or if, within the same rule, several sub-rules, apply to the same device based on the device’s intended purpose, the strictest rule and sub-rule resulting in a higher classification shall apply.
Just a question here. Have you begun your MDR transition planning and allocated a notified body under the MDR? Those who have their devices under the MDR are a little bit luckier as there are currently 20 notified bodies designated under the MDR.
MDR classification rules can be found in Annex 8 chapter 3. There’s potential for any of the 22 classification rules to apply to your device.
Software is classified in its own right (SaMD) or it takes the classification of the device it is incorporated in.
- Software may be classified under MDR rule 2, if incorporated in a blood or tissue storage device
- Software may be classified under MDR rule 10, if it is part of a therapeutic radiology device
- Software may be classified under MDR rule 15, this is class 2B if used for contraception
- Software may be classified under rule 22, which would be a class 3 device, if it is an active therapeutic device that significantly determines patient management
Now the MDR has its own specific rule for software, whereas the MDD did not have a specific rule for software. That rule is rule 10 under the MDR, and that rule reads software intended to provide information, which if used to make decisions with diagnosis or therapeutic purposes is classified as class 2a, except if such decisions have an impact that may cause:
- death or an irreversible deterioration of a person’s state of health, in which case it is in class 3 or
- a serious deterioration of a person’s state of health or a surgical intervention, in which case it is classified as class 2b
Other parts of this rule include software intended to monitor physiological processes, which is classified as class 2a. Except, if it is intended for the monitoring of vital physiological parameters, where the nature of variations of these parameters is such that it could result in immediate danger to the patient, in which case it is classified as class 2b. And the final part of rule 11 – all other software is classified as class 1.
Have you documented your classification, justification, and regulatory strategy? That is, of course, a requirement of both the MDR and the IVDR.