Medical device software is software that, alone or in combination, is intended for a medical purpose that falls under the definition of a medical device or an in vitro diagnostic. The decisive factor is the intended purpose defined by the manufacturer, not the technical platform, distribution channel, or designation as an app.
Qualification based on intended purpose
The software must perform a function that serves the diagnosis, prevention, monitoring, prediction, prognosis, treatment, or alleviation of a disease, or another medical purpose under the MDR or IVDR. Software may have this intended purpose on its own or operate in conjunction with a device. It remains medical device software even if it runs on a standard device.
Qualification first asks what action is intended based on the data processed. If an application, for example, outputs information intended to influence a clinical decision about a patient, its medical function must be assessed. Further classification follows only after this assessment and depends, among other things, on the significance of the information and the hazard situation.
Distinction from components, accessories, and general software
Software that controls a hardware product or influences its use, without itself having an independent medical purpose, may be a component or accessory of that product. It is not, for that reason alone, standalone medical device software. The relationship to the existing glossary term “medical device” therefore results from the intended purpose and the connection to the device.
Pure storage, archiving, transmission, simple search, or lossless compression of data does not, in itself, establish a medical intended purpose. A digital biomarker is also not automatically medical device software: only when the software is placed on the market with the intended medical function does the regulatory qualification apply. The label “AI” does not change this starting point.
Clinical evaluation or performance evaluation
For medical device software, the principles of clinical evaluation under the MDR or performance evaluation under the IVDR apply. The evidence must reflect the functional chain: input data, processing, output information, and its relevance to the intended use. For learning or frequently updated algorithms, it must also be explained which version was investigated and how changes are controlled.
Technical verification of the programming does not automatically demonstrate the clinical benefit of a decision-support tool. Conversely, a clinical study without a traceable validation of the underlying data may fail to demonstrate software performance. Risk management, usability, clinical evidence, and lifecycle documentation must therefore be aligned to the same intended use.
The intended purpose must be reflected consistently in the labelling, instructions for use, user interface, marketing claims, and technical documentation. Contradictory statements make qualification more difficult, because a functional description may imply a broader medical purpose than the formal product description. For networked systems, it is also necessary to delineate which component generates the medically relevant information.
For software with an IVD context, the performance evaluation must focus on the link between the analyte, the measurement system, and the clinical claim. For software under the MDR, the clinical effect of the information provided is often central. This distinction influences whether analytical, clinical, or both types of performance data are required in the documentation.
For a networked digital product, it must also be defined which data originate outside the software and which processing generates the regulated function. If information from different sources is combined, data quality, interfaces, and error scenarios must fit the intended use. The clinical claim can become unreliable if, for example, incomplete data transfer is not detected. Such limitations must be included in the risk and performance evaluation of the specific software function.
A software version is not merely a technical identifier. It makes it possible to assign clinical data, risk controls, and a user interface to the same investigated configuration. When changes are made, it must be assessed whether the medical purpose, the decision logic, or the demonstrated performance is affected. In this way, version control links development documentation with clinical evidence.
Relevance for clinical trials
Clinical studies of medical device software require a clear definition of the software version under investigation, the input data, and the intended users. For a diagnostic algorithm, for example, it must be distinguished whether the study investigates measurement accuracy, decision support, or patient-relevant benefit. Changes during the study can impair the comparability of the data and must be governed in advance through change management.
Full-service CROs such as Mediconomics support the translation of the intended purpose into study endpoints, versioning of the investigational software, data management for algorithmic inputs and outputs, and clinical evaluation documentation aligned with the intended use.
Frequently Asked Questions (FAQ)
Is every health app medical device software?
No. The decisive factor is whether the manufacturer defines a medical intended purpose; general wellness or administrative functions are not sufficient.
Does software become a medical device through data transmission?
No. Transmission, archiving, storage, and simple search do not result in qualification as a medical device without a medical intended purpose.
Can software both control a device and have its own medical purpose?
Yes. In that case, it must be carefully assessed which functions are components or accessories and which function is to be classified as standalone medical device software.
Regulatory References
- Regulation (EU) 2017/745 (MDR) — contains the definition and requirements for medical devices.
- Regulation (EU) 2017/746 (IVDR) — governs software with an IVD intended purpose.
- MDCG 2019-11 Rev. 1, Qualification and Classification of Software — provides guidance on qualification and classification.
- MDCG 2020-1, Clinical Evaluation of MDSW — explains the assessment of clinical or performance-related evidence.
