Telemedicine Software as Medical Devices

The purpose of this article is to evaluate the applicability of the medical device definition to telemedicine software, with consequent considerations in relation to Regulation (EU) 2017/745 (MDR) and current European and national regulations.
The analysis of the current regulatory context, in addition to considering the MDR, also includes specific MDCG (Medical Device Coordination Group) guidelines, in particular:

MDCG 2019-11 – Qualification and classification of software, which defines the criteria for the classification of software as a medical device.

Finally, Italian regulations related to telemedicine services will also be examined to verify their possible correlation with European rules for qualification and classification of software as medical devices.

Definition of Software as a Medical Device (MDSW)

As anticipated, the possibility of qualifying software as a medical device is linked not only to the medical device regulation but also to the indications contained in the MDCG 2019-11 guideline. This section highlights the key references to understand when software can be considered a medical device.

The first point of reference is the definition of medical device contained in Article 2 of Regulation (EU) 2017/745, which specifies that software can also fall into this category if it is intended by the manufacturer to be used on humans for medical purposes, such as diagnosis, monitoring or treatment of diseases or disabilities.

The MDCG, in turn, introduces a specific definition:

Medical device software (MDSW) is 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 medical devices regulation or in vitro diagnostic medical devices regulation.

A relevant point is the possibility that an MDSW can be stand-alone, i.e., independent of hardware, as long as it pursues a medical intended use.

The MDCG also clarifies a fundamental concept:

It is important to clarify that not all software used within healthcare is qualified as a medical device.

In reference to this concept, the MDCG also provides a practical example referring to software that allows healthcare professionals to search for clinical data on specific patients or to retrieve clinical records or other information. Such applications, although used exclusively in healthcare settings, typically do not have the necessary characteristics to be considered MDSW.

Another crucial passage emphasizes:

It must be highlighted that the risk of harm to patients, users of the software, or any other person […] is not a criterion on whether the software qualifies as a medical device.

This means that the potential risk to the patient is not a sufficient criterion to qualify software as a medical device.

In summary, five key points emerge from the regulatory and interpretative references mentioned above:

1. Software can be considered a medical device.
2. If it is, it takes on the connotation of MDSW.
3. An MDSW can be integrated into hardware or independent (stand-alone).
4. Use in healthcare is not in itself sufficient to define it as MDSW.
5. There is no correlation between potential harm to the patient and qualification as MDSW.

As can be seen, the MDR alone is not sufficient to provide an exhaustive qualification: the MDCG, while originating with the intent to offer interpretative clarifications, effectively introduces new concepts that directly influence regulatory assessment.
This trend will be even more evident in the following paragraphs.

The MDCG Decision-Making Scheme

Having clarified the concept of MDSW and the fundamental criteria to consider, the MDCG 2019-11 guideline proposes to manufacturers a decision-making scheme useful for establishing whether and how Regulation (EU) 2017/745 applies to their software.

Also in this case, it is important to emphasize that this is a peculiar approach: the decision-making process described by the MDCG does not coincide with that normally followed by manufacturers to qualify a medical device.

As will be noted, the scheme places technical and functional aspects at the center, rather than starting from the intended use, as is the case for most other medical devices. This is therefore a significant change in perspective.

Below is the complete scheme, which will then be analyzed step by step.

Step 1 – is it Software?

The MDCG 2019-11 defines software as:

A set of instructions that processes input data and creates output data.

In this logic, it is fundamental to understand what is meant by input and output data.

• Input data: any data provided to the software to generate a result, such as data entered via keyboard, touchscreen, voice, digital files (Word, PDF, DICOM, ECG, etc.) or received from other devices.
• Output data: any data produced by the software, such as screen displays, printouts, audio, digital documents, or tactile signals.

The definition is broad and technical, and serves to establish whether the analyzed object can fall within the scope of the guide.

Step 2 – is the Software an Accessory?

The second step requires evaluating whether the software:

• Falls within the products of Annex XVI (without medical purpose),
• Controls hardware or modifies its operation,
• Is an accessory to a medical device – for this last topic, a brief elaboration is necessary.

For the medical device regulation, an accessory is:

A product that, while not being a medical device itself, is intended by its manufacturer to be used together with one or more specific medical devices to specifically enable the medical device(s) to be used in accordance with its/their intended purpose(s) or to specifically and directly assist the medical functionality of the medical device(s) in terms of its/their intended purpose(s).

The MDCG clarifies that an accessory can:

• Control or modify the state of the device,
• Provide output functional to the device itself.

The manufacturer will therefore have to decide whether to evaluate the software as an integral part of the medical device or as an autonomous entity, subject to its own conformity assessment.

Step 3 – Does the Software Process Data?

Here we enter the heart of the decision-making scheme:

If the software does perform an action on data, or performs an action beyond storage, archival, communication*, simple search, lossless compression (i.e. using a compression procedure that allows the exact reconstruction of the original data) then it may be a medical device software (Refer to section 3.1 for more guidance on these software functions) proceed to step 4.

If the software does something more than just passive data management (such as search or archiving), then it could be an MDSW.

This is a fundamental step and the MDCG reiterates that the potential risk to the patient is not a sufficient criterion to qualify software as a medical device:

[…] the risk of harm to patients, users of the software, or any other person, […] is not a criterion on whether the software qualifies as a medical device

In practice: software can handle relevant or sensitive clinical data – such as to lead to extremely critical conditions for the patient – but if it does not process or interpret this data for a clinical purpose, it is not automatically an MDSW.

Step 4 – Does the Manufacturer Declare a Medical Purpose?

At this point, it is verified whether the manufacturer has attributed a medical intended use to the software.

This aspect is crucial: only the manufacturer can define the clinical purpose of their product. If this purpose is not explicitly stated, then the software does not fall under the definition of a medical device, even if technically it could.

This can become relevant in strategic or commercial terms: to exclude software from the scope of the MDR, it is sufficient not to declare clinical purposes.

Step 5 – is it Really a Medical Device?

Last step: verify if the software falls under the regulatory definition of MDSW, i.e., if it is intended for:

• Diagnosis, prevention, treatment or alleviation of diseases or disabilities,
• Modification or analysis of anatomical or physiological processes,
• Provision of information through in vitro examinations.

The placement of this step at the end of the decision-making scheme is unusual: for “classic” medical devices, this verification is the first and fundamental criterion.

For software, however, the MDCG suggests evaluating technical and functional aspects first, and then arriving, only as a last resort, at this formal definition.

Telemedicine and the Classification of Software as Medical Devices

The evolution of the boundary between generic software and MDSW (Medical Software) has simplified the distinction between products that fall into this category, thus reducing cases of borderline products. The separation is now clearer, facilitating the understanding of how to qualify software used in healthcare.

A relevant example concerns telemedicine, a field in which the definition provided by the Ministry of Health is as follows:

The term telemedicine refers to the entire set of healthcare services in which, thanks to the use of innovative technologies, the healthcare professional and the patient are not in the same place.

Telemedicine allows:

• Sending and receiving documents, diagnoses, and reports
• Assisting and conducting follow-up visits with patients
• Remotely monitoring vital parameters
• Enabling healthcare professionals to communicate for consultations on specific clinical cases

The Ministry also defines the main services that fall under telemedicine, including:

• Televisit
• Teleconsultation and medical-health teleconsultancy
• Teleassistance
• Telemonitoring

The definitions of these services are provided in the document National guidelines for the provision of telemedicine services.

The telemedicine services described above can be provided using software, but the mere provision of such services does not automatically imply that the software becomes a medical device. To be qualified as MDSW, software must meet specific qualification and classification criteria, which remain valid even for these applications.

In general, a distinction can be made between two categories of software:

1. Software that collects and transmits clinical data without processing.
2. Software that collects, transmits, evaluates and/or processes clinical data (for example, evaluating data against threshold values, calculating clinical scales, or generating alarms).

While the first type of software does not fall under the definition of MDSW, the second, thanks to its ability to process data, can be considered a medical device.

This distinction is supported by the analysis of the MDCG (Medical Device Coordination Group), which explains that general communication systems (such as email or video calls) are not medical devices, unless processing is performed on the transferred data.

In summary, to be considered an MDSW, software must do more than transmit data: it must process the data in a way that affects patient treatment or monitoring.

Conclusions

Based on the analysis conducted, the following key points emerge to consider in the context of qualifying and classifying software, with particular reference to software used in telemedicine contexts:

1. Software used in healthcare or clinical settings is not necessarily an MDSW.
2. The potential negative impact on the patient alone is not sufficient to qualify software as a medical device.
3. The qualification of an MDSW requires a joint analysis of Regulation (EU) 2017/745 and MDCG guidance documents.
4. The nature of telemedicine services does not automatically determine the qualification of the software that makes them accessible.
5. The technical and functional characteristics of software play a decisive and distinctive role in its qualification compared to other medical devices.
6. Software that does not process clinical data to generate new data intended for diagnostic or therapeutic decisions cannot be considered MDSW.
7. In the absence of a minimum complexity threshold defined by Regulation or MDCG, even simple processing of clinically relevant data may be sufficient to fall under the definition of a medical device.

The awareness and systematic application of these principles allow for preventing qualification and classification errors and represent a fundamental tool for defining the requirements and specifications of new software projects from the initial stages.