When is my software considered a medical device and what class is it?
Software is becoming more and more important and widespread in health services as it is in every field. Considering the many technology platforms (Ex: personal computers, smart phones, network servers, etc.) as well as the increasing ease of access and distribution (Ex: internet, cloud technology), software is in a wide range of uses in healthcare services.
These technological developments could not be ignored by the Medical Device Regulation (2017/745 MDR). When MDR examines, it is possible to see that new, different and more severe requirements for software have emerged. However, with the implementation of MDR, different terminologies belonging to software and the evaluation criteria of these terminologies have gained great importance.
However, not all software used in the healthcare industry is also a medical device. So when is my software a medical device? If it is a medical device, in which risk class should it be classified? What should be the conformity assessment route according to the determined risk class?
To answer this question in more detail, it would be useful to review and understand a guidance document published by the MDCG; MDCG 2019-11 Guidance on Qualification and Classification of Software in Regulation (EU) 2017/745 – MDR and Regulation (EU) 2017/746 – IVDR.
Mainly aimed at manufacturers of medical software, this guide provides guidance on the application of the qualification criteria for software covered by the new medical devices regulations (MDR and IVDR) and the classification criteria specified in Annex VIII of 2017/745 MDR and Annex VIII of 2017/746 IVDR. This guide also contains information on placing on the market.
In medical applications, it is generally possible to collect software in two main classes;
Software as a medical device (SaMD - Software As Medical Device); software that is a medical device on its own. (They are software that can work with any hardware defined by the manufacturer, without the need for hardware support.
Software that supports diagnostic processes as decision support software for medical professionals (Ex: Software for interpretation of ultrasound, MR images).
Software that can analyze various medical parameters and diagnose diseases (Ex: Patient Tracking Systems).
Software in Medical Device (SiMD Software In Medical Device); It is software that needs a certain hardware to work and is designed specifically for devices in general. (Also called Embedded or firmware)
The term Software as a Medical Device (MDSW), which includes both of the above terms, is explained in MDCG 2019-11 as follows.
Medical device software is software intended to be used alone or in combination for a purpose specified in the definition of "medical device" in the MDR or IVDR. In other words, MDSW is the most general term and covers both SamDi and SimDi.
European Commission, “Is your software a Medical Device?” published a decision tree to help with the question (Figure 1).
Şekil 1: MDR göre tıbbi cihaz yazılımının (MDSW) kalifikasyonunu desteklemek için karar adımları
Şekil 1: MDR göre tıbbi cihaz yazılımının (MDSW) kalifikasyonunu desteklemek için karar adımları
MDCG 2019-11 Guidance on Qualification and Classification of Software in Regulation (EU) 2017/745 – MDR and Regulation (EU) 2017/746 – IVDR guide document, MDR and IVDR software; defines it as a set of instructions that processes input data and produces output data. Input data is any data provided to a software to produce output data.
Input data types can be:
Output data can include:
The decision on whether it is a Medical Device Software can be made step by step according to the MDCG 2019-11 Guidance on Qualification and Classification of Software in Regulation (EU) 2017/745 – MDR and Regulation (EU) 2017/746 – IVDR guide:
Decision step 1: If the product is software pursuant to Part 2 (Definitions and Abbreviations) of the MDCG 2019-11 guide, it may be a medical device software, proceed to decision step 2; if the product is not software according to the definition in this guide, it is not covered by this guide but may still be considered under the MDR.
Decision step 2: If the product is a device or accessory of a medical device within the scope of an MDR Annex XVI, or software that directs or influences the use of a medical device, then it should be considered as part of that device in the regulatory process or independently if it is an accessory. If not, proceed to decision step 3.
Decision step 3: If the software is performing an operation on the data or other than storage, archiving, communication, simple search, lossless compression (i.e., using a compression procedure that provides exact reconstruction of the original data), it may be medical device software. . If it does not fulfill the above conditions, it is not an MDSW and is not considered under the MDCG-2019-11 guideline.
Decision step 4: If the software is for the benefit of individual patients, proceed to decision step 5. If the software is used not for the benefit of individual patients, for example, for pooling data from a population or for epidemiological studies, it is not an MDSW, is not covered by the MDCG-2019-11 guideline, and does not have to meet MDR requirements.
Decision step 5: If the software does not meet the MDSW definition according to the definition of the MDCG-2019-11 guideline, it is not covered by the MDCG-2019-11 guideline and does not need to meet the MDR requirements. If so, Medical Device Software (MDSW) is classified as software based on MDR requirements.
What is the class of software as a medical device relative to MDR or IVDR?
After the software is evaluated as a medical device, it is necessary to determine the classification rule of software that is a medical device according to 2017/745 MDR and the risk class of this rule. For this, it is necessary to refer to MDR Annex VIII, Rule 11. This rule is not included in the previous medical devices regulation, MDD, and was defined for the first time with MDR.
Rule 11 definition;
“Software intended to provide information used to make diagnostic or therapeutic decisions is classified as class IIa, except that such decisions have the effect of causing:
in case of death or irreversible deterioration of a person's state of health, he is in class III;
or a serious deterioration in a person's state of health or a surgical intervention is classified as class IIb.
Software for monitoring physiological processes is classified as class IIa, but is classified as class IIb if it is intended to monitor vital physiological parameters and changes in these parameters may pose an immediate danger to the patient.
All other software is classified as class I.
The point to note in the definition of this rule is that this rule only applies to SaMD.
In addition to this, if the software has been evaluated in the SiMD category (embedded or firmware), then there is no need to select a classification rule and risk class for this software. The most important consideration here is that since the SiMD software works with specific devices, the software and the device are considered as a whole and a common classification rule and risk class are chosen (this common class is usually the class of the device). To explain with an example; There is no need to select the risk class and classification rule of the embedded software in the Xray device that is used to operate this device. Since this software cannot work with a device other than the specific Xray device, the classification rule and risk class of the X-Ray device will apply. Since the Xray device and software work in combination, no separate technical documentation should be prepared for the software. Relevant data should be added in the software part of the technical documentation of the Xray device.
You stumbled upon this article by chance and couldn't decide whether your planned application might fall under the MDR or IVDR? Are you new to the industry? Do not hesitate, experienced Infigen Consultancy, which has been dealing with certification processes for 20 years, can assist you in your studies.
Please note that all details and information from Infigen Consultancy do not claim to be complete and are for informational purposes only.
TR | TR
