Medical grade software

Tuesday 10 December 2019

‘We develop medical grade software,’ claim manufacturers and development service providers, without specifying what exactly they mean by ‘medical grade’. This definition is important. It is the only way to assess to what extent this software can contribute towards the fulfilment of regulatory requirements.

Manufacturers advertise with the term ‘medical grade software’. In addition, new test seals and ‘certificates’ are sprouting up everywhere.

As a medical device distributor, you need to be careful to avoid inadvertent non compliances and unnecessary work and expense.

  Content overview

1. Examples »

2. Definitions »

3. Requirements »

4. Review »

1. Examples of medical grade software

There is software that is not a medical device in itself but which, according to the manufacturer, can be used as part of a medical device or for other purposes in public health care. However, more often than not, manufacturers do not want to restrict the use of this software to public health care.

Examples of such software products are:

  • software that renders a 3D solid model, which is also to be used in medical devices for diagnostic analyses
  • components (e.g. a DLL) for image editing for example for edge detection, which is also to be used in medical devices for segmenting and/or radiotherapy planning, for instance
  • integration servers, which can transform different communication protocols and route information flows and are also to be used in the medical context. For example, to link clinical information systems and medical devices like laboratory equipment
  • apps which serve as a patient diary but are not medical devices

software which serves medical purposes but is not considered to be a medical device by MEDDEV 2.1/6 or its successive guideline MDCG 2019-11 as it is only used for storing or forwarding (medical) data, for instance

Further information

Read more on the subject of classification of software as a medical device here.

Legal requirements referring to medical devices, such as the MDR, do not affect these software applications or components as they are not medical devices. However, developers and manufacturers want to make a point and so often speak of medical grade software.

Similar points are made about medical grade PCs or medical grade hardware. Here too, these terms are often not defined or there is no common understanding of them.

2. Definitions and classification

IEC 82304 defines the term health software:

 Definition: health software

‘Software intended to be used specifically for managing, maintaining or improving health of individual persons, or the delivery of care.’

Source: DIN EN IEC 82304-1:2018-04

‘Software intended to be used specifically for managing, maintaining or improving health of individual persons, or the delivery of care.’

Source: DIN EN IEC 82304-1:2018-04

Contrary to health software, medical grade software is not necessarily intended for ‘managing, maintaining or improving health of individual persons’.

Medical grade software is normally understood to be software that is developed in compliance with the regulatory requirements referring to medical device software without necessarily being an actual medical device or component.

Medical devices and health software must achieve at least medical grade level. However, the requirements go beyond those of software which claims to be medical grade, as explained in the next section.

Further information

You can see the definitions of the terms ‘Software as a Medical Device’ and ‘medical device software’ in the article ‘Software as a Medical Device’.

3. Regulatory requirements

As the term ‘medical grade software’ is not defined, no specific regulatory requirements can be named.

However, it can be assumed that with their ‘medical grade’ declaration, the manufacturer wishes to indicate that the software is suitable for use in health applications and even medical devices.

However, distributors of medical devices must be aware that manufacturers of ‘medical grade software’ (MGS) can only meet these requirements to a certain extent:

Requirements (including safety and performance requirements)

Can proof be provided?


Software life cycle processes


e.g. conformity with IEC 62304

Software verification


e.g. conformity with IEC 62304

Software validation incl. clinical validation and usability validation


Only the device made with it can be validated.

Risk management

Not as a rule

MGS manufacturers often do not know the technical and clinical context well enough.

IT security

To a large extent, yes

IT security also includes organisational aspects and is specifically for hardware. Neither applies to MGS manufacturers.

Data protection

More no than yes

Organisational measures and the legal bases for data processing can only be determined by the distributor. The MGS manufacturer can ‘only’ establish the technical requirements (> IT security).

Accompanying and training materials


The accompanying materials must reveal the residual risks, among others. This is the distributor’s responsibility.

Post-market surveillance

To some extent

MGS manufacturers should gather information on their software on the market and pass it on to distributors.


The more obvious it is that software requirements have a medical purpose, the stricter they become:



Regulatory requirement

Medical device software

Own medical purpose
Software supports medical mechanism of action

Laws on general device safety
MDR, MDD, etc.
QM system
(Harmonised) standards

Health software that is not medical device software

Serves a medical/health-related purpose but is not covered by the definition of the term ‘medical device’

Laws on general device safety
QM system
IEC 82304
IEC 62304
ISO 14971
IEC 62366-1

Medical grade software that is not health software

No individual medical purpose
supports the technical operating principle

Laws on general device safety
QM system
IEC 62304

4. Review and conclusion

a) Rapid growth of certificates, test seals and claims

The MDR very clearly states the requirements regarding medical device software. However, other institutions feel obliged to establish further requirements and catalogues of criteria, as the following examples show:

To some extent, these catalogues of criteria also refer to software that is not a medical device or part of one.



b) Problems for manufacturers and users

This inundation of catalogues leads to specific problems:

  1. For patients the number of test seals and certificates is becoming more and more confusing. This not only applies to the amount of seals and certificates but also their binding nature and validity.
  2. For manufacturers these sometimes superfluous tests and certifications mean more work and expense. It is necessary to draw up specific documents, fill out forms and pay fees.
  3. The scope and test procedures (not to be confused with the test criteria) are sometimes unclear or are not accurately set out. This makes specific preparation difficult.
  4. Every professional testing institute must itself be tested and accredited. It is precisely this hurdle that many self-declared ‘certifiers’ do not wish to overcome. Externally tested quality assurance should not only be obligatory for manufacturers but also for testing organisations.

We should ensure that this proliferation of certificates and test seals does not degenerate into a modern-day highway robbery behind the smokescreen of patient safety.

c) Special case of medical grade software

Declarations on medical grade software must be regarded even more cautiously than the above-mentioned proof. Without traceable tests with specific, transparent test criteria, test procedures and test results (ideally through an accredited testing organisation) a declaration that software is medical grade software is only useful to a limited extent.

Manufacturers of medical grade software, who wish to use such software in or with their medical devices, should specifically set out what they understand by the term ‘medical grade’ and what proof they have provided to support this implicit quality claim.

These manufacturers should also define as clearly as possible a non-medical purpose and possible use in a medical device.

d)  Classification of medical devices

Because medical grade software is meant to support the functions of a medical device, it can easily become a medical device itself or an accessory. Whether this is the case depends on whether it provides more support for the technical or the medical operating principle of the medical device.

MEDDEV 2.1/6, and its successive guideline MDCG 2019-11 respectively, help with this classification. If the manufacturer determines an intended purpose that is not related to the medical domain (e.g. calculating a 3D volume) or that is more technically formulated (e.g. controlling specific hardware), this indicates that the software counts as medical grade software but not as an independent medical device.

However, it can be classified as medical device software in terms of guideline MDCG 2019-11, which is part of a medical device.

e) Conclusion

It shouldn’t matter whether the software developed is medical device software, medical device software or Software as a Medical Device1). Manufacturers should develop all kinds of software ‘fairly’. IEC 62304 establishes the lower limits of what can be described as fair.

Transparency creates trust. This applies to software that claims to be medical grade software.

Thank you very much to Robert Dick-Hambeck for his suggestions and contents.
1) The terms are not disjunctive.



Prof. Dr. Christian Johner

Find out what Johner Institute can do for you

A quick overview: Our


Learn More Pfeil_weiß

Always up to date: Our


Learn More Pfeil_grau

Privacy settings

We use cookies on our website. Some of them are essential, while others help us improve this website and your experience.