MDR Guide for

Medical Device Software

MDR Guide for Medical Device Software

 Motivation
The Dutch authority VWS organized stakeholder meetings for the implementation of
the MDR in the Netherlands. In 2018 VWS organized special stakeholder meetings
for software under the MDR. The Dutch parliament raised questions since there was
a concern that the MDR was a roadblock for Start-ups and manufacturers of Apps.
Therefore, a VWS taskforce for Medical Device Software (MDSW) was initiated to create a
“simplified” MDR Guide for Medical Device Software.

Figuur 1 Figure 1Figure

MDR1Guide
MDR Guide for MDSW
for MDSW timelines
timelines

2018 2019 2020 Q1 2021 Q1 26 May 2021

VWS Kamervragen MDR

Klankbord- MDR Startups DoA
groep & Apps

VWS Werkgroep MDR guide

Verdiepende MDR Software for MDSW
sessie Software

Figuur 2 Figure 2 MDR Guide overview for MDSW

Chapter 1 Technical Documentation Quality Management System (QMS)

The focus ofIntroduction
this MDR Guide for Medical MDRDevice Software
Annex II (& III) is: MDR art 10 (+ ISO 13485)
• To cover MDSW, including related hardware aspects.
5 Pre-Market (Annex II):
• To explain aspects
Chapter 2 of the MDR, which
- GSPR (MDRareAnnex
neededI) to get 6CEQualify Management
certified.
System Manual
6 Quality Records:

• To identifyMDR Overview aspects needed

additional - Softwarefor MDSW, Life
Development such as privacy and cybersecurity. - Purchasing & Production
Cycle Procedures: Records
• To provide
3 a workflow to implement the MDR and give insight
- Risk Management
in the
- Complaint implementation
Handling - Sales & Service Records
costs. So, aChapter 3 project plan- can
realistic
Qualification & Classification
be created.
Cybersecurity - (Purchasing) - Agreements
- Clinical Evaluation & - (Production) - Complaint Records
• To give insight to Start-ups what Investifation
expertise has to be acquired. - (Sales & Service) - (Training records)
4 - IFU & Label - (Registrations)
Chapter 4 Organization:
The purposeCEofMarking
this Guide is not: - PRRC Significant changes
6 Post-Market: (Annex III)
• Guidance,
5
since this would have- put
PMS &limits
PMCF to what could have beenRep
- Authorized explained.
- Importer & Distributor
• TranslatingChapter 5 in Dutch. The English terminology is most used, and many users
the MDR
Technical Documentation
only can read English.
• Covering
6 the IVDR, Custom Made
Chapter 6
Software and In-House6 Developed
4 CE Marking: Software. - EUDAMED:
European Database
- Qualification & Classification - Actor Registration - Clinical Investigation
Quality Management System 3 - Conformity Assessment - UDI (Unique Device - Vigilance
This MDR Guide for Medical Device Routes
Software was created under considerable
Identification) time -pressure
Market Surveillance
- Assessment of Technical - Certificates
to be ready before
Chapterthe
7 implementation of the MDR, limiting how far certain subjects could
Documentation & QMS
MDR related costs
be worked out. Therefore, a maintenance update on a later date is planned for:
• 5.4 Software Development Life Cycle: Agile Development.
• 5.5 Risk Management: Software Risk Management techniques.
• Interoperability: Health Apps.
• 5.9 Clinical Evaluation: Artificial Intelligence.

MDR Guide for Medical Device Software 2

Figuur 1 Figure 1 MDR Guide for MDSW timelines

Guide overview
2018 2019 2020 Q1 2021 Q1 26 May 2021

VWS Kamervragen MDR

Klankbord- MDR Startups
• EU: Implementation
groep &Model
Apps for medical devices Regulation Step by Step Guide
DoA

The setupVWSof the Guide follows a process flow. See chapters on the left side of the image.
Werkgroep MDR guide
Verdiepende
The chapters are linked to areas inMDR
the Software
MDR, see the
forright
MDSWside of the image. Per chapter
sessie Software
or paragraph, the relevant MDR articles or Annexes are given. In addition, also the
guidance is mentioned and other useful documentation.

Figuur 2
Figure 2 MDR Guide overview for MDSW
Figure 2 MDR Guide overview for MDSW

Chapter 1 Technical Documentation Quality Management System (QMS)

Introduction MDR Annex II (& III) MDR art 10 (+ ISO 13485)

5 Pre-Market (Annex II): 6 Qualify Management 6 Quality Records:

Chapter 2 - GSPR (MDR Annex I) System Manual
MDR Overview - Software Development Life - Purchasing & Production
Cycle Procedures: Records
3 - Risk Management - Complaint Handling - Sales & Service Records
Chapter 3 - Cybersecurity - (Purchasing) - Agreements
Qualification & Classification - (Production) - Complaint Records
- Clinical Evaluation &
Investifation - (Sales & Service) - (Training records)
4 - IFU & Label - (Registrations)
Chapter 4 Organization:
CE Marking - PRRC
6 Post-Market: (Annex III) Significant changes
- Authorized Rep
5 - PMS & PMCF
Chapter 5 - Importer & Distributor
Technical Documentation

6 4 CE Marking: 6 European Database - EUDAMED:

Chapter 6 - Qualification & Classification - Actor Registration - Clinical Investigation
Quality Management System 3 - Conformity Assessment - UDI (Unique Device - Vigilance
Routes Identification) - Market Surveillance
Chapter 7 - Assessment of Technical - Certificates
MDR related costs Documentation & QMS

The guide has the following structure:

1. Chapter 1 Introduces the MDR guide for MDSW.
2. Chapter 2 Introduces the MDR and gives an overview of its contents.
3. Chapter 3 Explains Qualification. During qualification it is investigated if the software
is within the scope of the MDR and therefore has to follow the regulations within
the MDR. Qualification is a comparison of the intended use of the software and the
definition of the Medical Device. If it matches, then the software is called MDSW.
Chapter 3 Explains also Classification. Classification determines the risk class of
the Medical Device. The higher the risk class the stricter the MDR requirements
are. Classification is comparing the intended use of the Medical Device with the
classification rules.
4. Chapter 4 Explains the CE marking. The CE mark is a symbol on MDSW that shows
that the product is allowed according the MDR to be sold on the market. In most
cases for MDSW a Notified Body reviews the technical documentation and audits the
quality management
MDR Guide system (QMS) before the CE can be applied. A Notified Body is a
for Medical Device Software 1

technical competent organization appointed by the Competent Authority (the national

government) and the European Commission. When the Notified Body are successful,
then the MDSW is CE certified and the Manufacturer is allowed to sell the product.
The risk class determines the detailed certification steps, which is called a conformity
assessment route.
5. Chapter 5 Describes the content of the Technical Documentation. The Technical
Documentation contains the evidence that is created during the development process,
so that the Notified Body can review the quality of the MDSW and if all related MDR
requirements are fulfilled. The Manufacturer uses a GSPR checklist, to show where

MDR Guide for Medical Device Software 3

 the evidence for the Software Development (Life Cycle), Risk Management, Clinical
Evaluation and other processes can be found in the Technical Documentation.
6. Chapter 6 Describes the QMS. ISO 13485 contains the requirements for a QMS of
Medical Devices. The QMS contains the procedures which describe the activities
needed to develop, purchase, produce, sell and service a MDSW. The QMS also
describes the organization of the Manufacturer and its external relations with
amongst other suppliers, importers, and distributor. Evidence for the execution of the
QMS activities have to be documented in so called Quality Records. In most cases the
Notified Body audits the QMS to review if the related MDR requirements are fulfilled.
7. Chapter 7 Describes the MDR related costs. This chapter describes the resources
needed to implement the MDR. Without management support, a decent project plan,
dedicated project manager and allocation of resources, most MDR project will be a
struggle. The chapter also gives a Start-up insight in what resources and activities
need to be financed.

Document references

• M
 DR Guide for Medical Device Software, version 1.0 – 16 July 2021
https://fme.nl/mdr-guide-medical-device-software

Disclaimer: Information and interpretation presented within this guide is based on the current understanding of
the Medical Device Regulation and is intended for information purposes only and not intended to give advice.
Please check the information before use, with the official publications. Please check the interpretations before
use, with the responsible authorities. The author shall not be liable for any losses, actions, claims, proceedings,
demands, costs, expenses, damages, and other liabilities whatsoever caused arising directly or indirectly in
connection with, in relation to or arising out of the use of this guide. The author shares his personal view and
experience and the information provided in this guide was created independently. This guide was peer reviewed,
however this guide should not be used to base conclusions on.

MDR Guide for Medical Device Software team:

• Claire de Monte (VWS)
• Laurine Keulemans (VWS)
• Jan Jaap Baalbergen (NFU)
• Robert van Wijk (OIZorg / FarMedvisie)
• Luc Knaven (FHI)
• René Drost (NAMCO)
• Roel Barelds (Tenzinger)
• Corine Böhmers (Health Innovation Park)
• Leo Hovestadt (FME / Elekta)
And of course, thanks to all the reviewers.

Copyright © 2021 by Leo Hovestadt.

This document is put in the Public Domain under a Creative Commons CC0 license.
Free for commercial use. No attribution required.

Contact: Inaccuracies and suggestions for improvement of this document can be sent to
Leo Hovestadt via the contact form where this guide is published.

MDR Guide for Medical Device Software 4

 Table of Contents
Motivation  2

Guide overview  3

Document references  4

Table of Contents  5

1. Introduction  7

2. MDR Overview  8
2.1. MDR background  8
2.2. MDR key concepts  8
2.3. MDR structure  9
2.4. MDR and other regulations  10
2.5. In-house developed software  10

3. Qualification and Classification  12

3.1. Introduction  12
3.2. Intended purpose and claims  13
3.3. Qualification  13
3.4. Classification  15
3.4.1. Implementing rules  15
3.4.2. Classification rules  16
3.4.3. Classification rules 11 17
3.5. Requirements related to risk class  18

4. CE Marking  19
4.1. Introduction  19
4.2. Conformity Assessment route  19
4.3. Competent Authority and MDCG  20
4.4. Notified Body  21
4.5. Declaration of Conformity and CE Marking  22
4.6. Free sales certificates  22

5. Technical Documentation  23
5.1. Introduction  23
5.2. Technical Documentation (on Post-Market Surveillance)  23
5.3. General Safety and Performance Requirements (GSPR)  25
5.3.1. GSPR checklist  25
5.3.2. Applicable Standards  26
5.4. Software development life cycle  27

MDR Guide for Medical Device Software 5

 5.5. Risk management  28
5.5.1. Introduction  28
5.5.2. Risk Management Plan  29
5.5.3. Risk analysis, evaluation and control  29
5.5.4. Risk control  30
5.5.5. Risk management report  30
5.6. Clinical Evidence  30
5.6.1. Introduction  30
5.6.2. Clinical Evidence documentation  31
5.6.3. Pre-Clinical, Clinical Data and MDR art 61(10)  32
5.6.4. Clinical Evidence  33
5.6.5. Clinical Evaluation  38
5.6.6. Clinical Development Plan  40
5.6.7. Clinical Investigation  41
5.7. Usability  42
5.8. Cyber security  44
5.8.1. Introduction  44
5.8.2. Cyber security risk management  45
5.8.3. Secure Development Life Cycle (SDLC)  46
5.8.4. (Self)-certification  46
5.9. GDPR (Privacy)  46
5.9.1. Personal Data  46
5.9.2. Roles and Responsibilities  47
5.9.3. Access, Rectification and Erasure  47
5.9.4. Profiling  48
5.9.5. Data Portability  48
5.9.6. Risk Management  48
5.9.7. Privacy by Design (GDPR)  48
5.9.8. Privacy by Default (GDPR)  49
5.10. Interoperability  49
5.11. IFUs, labels, brochures and website  51
5.11.1. IFUs and labels  51
5.11.2. Promotional and informational materials  52

6. Quality Management System  55

6.1. Introduction  55
6.2. ISO 13485 and MDR art 10  56
6.3. Person responsible for regulatory compliance (PRRC)  57
6.4. Economic Operators  58
6.5. UDI (traceability) and EUDAMED  60
6.5.1. UDI introduction  60
6.5.2. UDI system overview  61
6.5.3. UDI for MDSW  63
6.5.4. EUDAMED introduction  64
6.5.5. EUDAMED database structure overview  64
6.6. MDR, EUDAMED and Trade Agreements in transition  65
6.7. Post Market obligations  67
6.7.1. Post Market Surveillance and Post Market Clinical Follow-Up  67
6.7.2. Complaint Handling, Vigilance reporting and Market Surveillance  70
6.7.3. Maintenance, updates, upgrades, lifetimes and warrantees  73
6.7.4. Significant changes after placing the product on the market  74

7. MDR related costs  76

Appendix 1: Resources and hyperlinks  78

Appendix 2: Terms, abbreviations and translations  80

MDR Guide for Medical Device Software 6

01
Introduction

The Medical Device Regulations (MDR) is applicable from 26 May 2021 for all Medical
Devices in Europe. The MDR has a huge impact on App developers and MDSW
manufacturers. The MDR brings many new requirements and often also more stricter
requirements because of up-classifications. The MDR introduces an extension of the
definition of software as a medical device. Software devices that fall under the scope
of this definition is MDSW as a module of a software solution or as an accessory to a
Medical Device.

The translation of the MDR requirements into practical actions is complex and resource
heavy. Therefore a work group of experts with affiliations within the national Branch
Organizations Nederlandse Federatie van Universitair Medische Centra (NFU), Federatie
van Technologiebranches (FHI), Ondernemersorganisatie voor de Technologische Industrie
(FME) and Organisatie ICT-Leveranciers in de Zorg (OIZorg) in coordination with the Dutch
Ministry of Health (VWS) developed a Guide in response to the many questions coming
from Software manufacturers including start-ups.

The Guide intends to:

1. P
 rovide an explanation of the steps and challenges for a (start-up) software
manufacturer to successfully place MDSW on the market under the MDR. A companion
document for in house-made software is made separately by the NFU but is not publicly
available.
2. Explain the key concepts of the MDR.
3. P
 rovide an overview of the qualification and classification steps of the MDR.
Qualification is the process of determining if software is a medical device according to
the MDR and should therefore follow the requirements of the MDR. This software is
then called MDSW.

Note: MDSW can also be delivered in combination with hardware, therefore also hardware
aspects are discussed in this guide.

Note: Out of scope of this Guide is In Vitro Diagnostic Software, ”Custom Made Software”
and ”In-House Developed Software” such as In-House-Developed Radio Therapy Software.

Note: It is expected from the reader to have at least some understanding of the
consequences of the Medical Device Regulation. This Guide will offer an overview of the
MDR. For the translation of the MDR to your business and product development process
you might still need an expert or consultant, with in depth knowledge of the MDR and an
understanding of your business and your software products. The content of this Guide is
strictly informative and has no legal status.

MDR Guide for Medical Device Software 7

 02
MDR Overview

2.1. MDR background

The MDR is applicable for placing a medical device on the market in the EU. After many
years of discussion, the European Parliament and Council adopted the Medical Device
Regulation (MDR) in May 2017. The MDR regulates the required steps until a medical
device for human use can be placed on the European market as well as the resulting
post-market actions. It will be applicable from 26 May 2021 onwards and has replaces
the current Medical Device Directive (MDD – 93/42/EEC) and Active Implantable Medical
Device Directive (AIMDD – 90/385/EEC). The MDR is applicable for the EEA (EU and
Iceland, Liechtenstein and Norway) and other countries that have an agreement with the
EU to follow the MDR.

2.2. MDR key concepts

• EU: Medical Device Regulation (MDR) 2017/745

• EU: Factsheet for Manufacturers of medical devices
• Medtech Europe: Medical Devices Regulation – Flowchart

To place a Medical Device in the EU, the device and the Organization selling the Medical
Device need to conform to the applicable legislation. This legislation is called the Medical
Device Regulation. For higher risk class Medical Devices both the Product and the
Organization need to be certified. Certification is checking that the requirements specified in
the MDR are fulfilled and this is then followed by certification (officially approval). When the
Organization is certified, this is called a Quality Management System (QMS) Certification.

Figuur 3 Figure 3 Overview of MDRofkey

Figure 3 Overview MDRconcepts
key concepts

Technical Documentation Quality Management System (QMS)

MDR Annex II (& III) MDR art 10 (+ ISO 13485)

Pre-Market (Annex II): Qualify Management Quality Records:

- GSPR (MDR Annex I) System Manual
- Software Development Life - Purchasing & Production
Cycle Procedures: Records
- Risk Management - Complaint Handling - Sales & Service Records
- Cybersecurity - (Purchasing) - Agreements
- Clinical Evaluation & - (Production) - Complaint Records
Investifation - (Sales & Service) - (Training records)
- IFU & Label - (Registrations)
Organization:
Post-Market: (Annex III) - PRRC Significant changes
- Authorized Rep
- PMS & PMCF
- Importer & Distributor

CE Marking: European Database - EUDAMED:

- Qualification & Classification - Actor Registration - Clinical Investigation
- Conformity Assessment - UDI (Unique Device - Vigilance
Routes Identification) - Market Surveillance
- Assessment of Technical - Certificates
Documentation & QMS

MDR Guide for Medical Device Software 8

Figuur 4

Table 1 MDR Preamble, Chapters and Annexes

 The product certification is done by a Notified Body. A Notified Body is an organization
which can certify and is notified (appointed) by the European Commission. The product
certification is done based on the documents in the Technical documentation. For risk
class I products (excluding products with a measurement function, Im, sterile products, Is,
and re-usable surgical instruments, Ir) the Manufacturer can self-certify its products. The
Technical documentation can be requested by the Competent Authority who might check
its contents.

The QMS certification is normally certified by the Notified Body. The QMS certification
is done based on the procedures in the QMS manual and on the Quality Records which
contain evidence that the procedures of the QMS Manual are followed. For risk class I
Figuur 3 Figure 3 Overview of MDR key concepts
products, a certification by a Notified Body is not necessary, however it is possible that
the Competent Authority will perform an inspection.
Technical Documentation Quality Management System (QMS)
MDR Annex II (& III) MDR art 10 (+ ISO 13485)
InPre-Market
the European
(Annex II):
database the Manufacturer, theQuality
Qualify Management
Notified
Records:
Body and the Competent
Authority haveI)to upload data
- GSPR (MDR Annex Systemrelated
Manual to the Certification process of the Manufacturers
- Software Development Life
Organization
Cycle
EUDAMED is not yet- Purchasing
and Products.Procedures: ready, so
Records
& Production
now there are transition
provisions in place.
- Risk Management - Complaint Handling - Sales & Service Records
- Cybersecurity - (Purchasing) - Agreements
- Clinical Evaluation & - (Production) - Complaint Records
Investifation - (Sales & Service) - (Training records)
2.3. MDR structure
- IFU & Label
Organization:
- (Registrations)

Post-Market: (Annex III) - PRRC Significant changes

- Authorized Rep
The
- PMSMDR
& PMCFhas the following- Importer
sections:& Distributor
• P reamble. The pre-amble is used as background information and consideration for the
development of the MDR.
CE Marking:
In general, this section
European Database
is not used by manufacturers, but can
- EUDAMED:
help in the
- Qualification interpretation.
& Classification - Actor Registration - Clinical Investigation
•- Conformity
Chapters
Routes
Assessment
with Articles. The chapters are used-- to
- UDI (Unique Device
Identification)
Vigilance
divide the MDR in logical sections
Market Surveillance
Every chapter
- Assessment has several- Certificates
of Technical articles with requirements.
• Documentation
Annexes. The & QMS
Articles sometimes refer to Annexes where further detail about an article
is given.

The following table shows the major sections of the MDR:

Figuur 4

Table 1 MDR Preamble, Chapters and Annexes

Table 1 MDR Preamble, Chapters and Annexes

Preamble | Chapters with Articles

I Scope & definitions
II Making available of devices, obligations of economic operators, reprocessing, CE marking, free movement
III Identification and registration of devices and economic operators, summary of safety and clinical performance, EU medical
device databank
IV Notified bodies
V Classification and conformity assessment
VI Clinical evaluation and clinical investigations
VII Vigilance and market surveillance
VIII Cooperation between Member States, Medical Device Coordination Group, EU reference laboratories, device registries
IX Confidentiality, funding, penalties
X Final provisions
Annexes
I General Safety & Performance Requirements
II Technical Documentation (including PMS)
III Technical Documentation on Post Market Surveillance
IV EC Declaration of Conformity
V CE Marking of Conformity
XI Product Conformity Verification
XII Conformity Assessment for Custom-Made Devices
VIII Classification Rules
IX Conformity Assessment for Quality Management System and Technical Documentation
X Conformity Assessment for Type Examination
XI Conformity Assessment for Product Conformity Verification
XII Content of Certificates Issued by a Notified Body
XIII Procedure for Custom-Made Devices
XIV Clinical Evaluation and Post Market Clinical Follow-up
XV Clinical Investigations
XVI List of Non-Medical Products Included in the MDR

MDRGuide
MDR Guideforfor Medical
Medical Device
Device Software
Software 2 9
When the MDR was created, several parts could be more detailed by additional legislation.
Therefore, it was possible to create extensions for the European Commission, called
Implementing Acts and for the Competent Authorities called Delegated Acts. These acts
also required as the MDR itself. To correct small mistakes in the MDR corrigenda are
published.

To help with the interpretation of the MDR there are guidance documents provided by the
MDCG, called MDCG guidances. The old Meddev guidance is still used often, however the
Meddev guidance is officially no longer applicable after 26 May 2021. In addition to the
MDR guidance documents, the following documents from the European Commission or
Competent Authorities are available:

• “Blue guide” on the implementation of EU product legislation.

• Exhaustive list of requirements for manufacturers of medical devices.
• Implementation Model for Medical Devices Regulation - Step by Step Guide.
• CAMD - FAQ – MDR Transitional provisions. Note this guidance should have been
updated for the new transition dates.

For specific products or activities there are Common Specifications or Harmonized

Standards. A Common Specification has to be fulfilled and a Harmonized Standard contains
guidance for which alternatives may be used.

EC countries have legislations and regulations supporting the implementation of the

MDR. These typically contain regulations for what needs to be locally arranged. Think of
translation requirements or which department performs which task for the MDR within the
national government.

2.4. MDR and other regulations

The MDR also has implementations in local legislation which has impact. The major
elements in the Netherlands are:

• M
 edical Devices Law (Wet medische hulpmiddelen, analoog aan de andere hieronder.),
specifying requirements for:
- Code of Conduct (Gedragsregels).
- Fees and Fines (Vergoedingen en boetes).
- Competencies Dutch Authority (Bevoegdheden NL overheid).
- Clinical Investigations (Klinisch Onderzoek).
• Medical Devices Decree (Besluit medische hulpmiddelen), specifying requirements for:
- Implant card and National Register of Implants (Landelijke Implantaten Register (LIR)).
- Reprocessing of single use products.
• Medical Devices Rule (Regeling medische hulpmiddelen), specifying requirements for:
- Language requirements.
- Certificate of Free Sales.
- Custom-Made Devices.

2.5. In-house developed software

• MDR art 5(5) Definition (1) Medical Device

• IEC 62304 MDSW development process

A companion document for in house-made software to the MDR guide is made separately
by the NFU but is not publicly available. MDR art 5(5) makes it possible for health
institutions to develop, manufacture and use medical devices in their own house, provided
that the following conditions are met:
• The devices fulfil the General Safety and Performance Requirements (GSPR) as described

MDR Guide for Medical Device Software 10

 in MDR Annex I.
• The devices are not transferred to another legal entity.
• The devices are manufactured and used under an appropriate quality management
system.
• An equivalent device is not available on the market.
• The health institution provides information upon request on the use of such devices to
its competent authority.
• The health institution draws up a public declaration on the use and justification of the
devices.
• The health institution draws up documentation describing the design, manufacturing
facility and process and the performance of the device, showing the device to follow the
relevant GSPR.
• The health institution reviews experience gained from clinical use of the devices and
takes all necessary corrective actions.

MDR art 5(5) makes it clear that the performance and safety requirements for in-house
developed medical devices are the same compared to a MDR CE marked medical devices.
Under MDR art 5(5) there is no obligation for health institutions for CE marking In-
house developed software and certifying the quality management system, unless these
devices are transferred to another entity. In that case the health institution becomes
a manufacturer and has to act like a manufacturer. To comply to the state-of-the-art
software development, the IEC 62304 MDSW development process is recommended.

MDR Guide for Medical Device Software 11

3
Qualification and Classification

3.1. Introduction
• T
 his chapter explains Qualification. During qualification it is investigated if the software is
within the scope of the MDR and therefore has to follow the regulations within the MDR.
Qualification is a comparison of the intended use of the software and the definition of the
Medical Device. If it matches, then the software is called MDSW.

 utside the EU MDSW is often called Software as a Medical Device (SaMD). That definition
O
should not be used since it can lead to incorrect qualification and classification of the
MDSW. Software “Qualifies” according to the MDR if it meets the definition for “Medical
Device” MDR art 2(1). Note that software that is qualified according to the IVD, IVD MDSW
has to follow the requirements of the IVDR. These requirements are closely related to the
MDR requirements, however there are quite a few differences. The IVDR requirements are
not described in this guide.

• T
 his chapter also explains Classification. Classification determines the risk class of
the Medical Device. The higher the risk class the stricter the MDR requirements are.
Classification is comparing the intended use of the Medical Device with the classification
rules. The classification rules are mentioned in the MDR Annex VIII.

• T
 o help with the Qualification & Classification there is guidance MDCG 2019-11
Qualification and Classification of software. Classification is considered to be very
complex, and it is very normal to use external expertise for correct Qualification and
Classification purposes. It is considered good practice to document the argumentation for
both the Qualification and Classification. The qualification and classification steps are:

Table 2 Qualification and classification steps

Step Remarks
1. E lements (Device, Module or Accessory) with a CE mark need to be
1 Define the Medical Device elements: qualified separately (in its own right). Elements without a CE mark
Medical Device; Module or Accessory do not need to be qualified. Further explanation about modules can
be found in MDCG 2019-11 chapter 7 Modules.
2 Determine per Medical Device elements: 2. For each element the intended purpose needs to be determined.
The intended purpose and claims Claims about safety, performance, risks and benefits also need to be
considered.
3. The qualification is performed and based on the definitions of a
3 Medical device and MDSW and the intended purpose and claims.
Qualify each Medical Device elements
The result is the qualification as a Medical Device or MDSW, or not.
4. The classification is performed based upon the intended purpose
and claims according to the classification rules and implementing
4 Classify each Medical Device elements rules (how to perform the classification). The result is a risk class of
according the implementing rules
the device.
5. Documenting the rationale for the qualification and classification
5 Document the qualification is important, as it is the basis for the certification process to be
and classification followed.

MDR Guide for Medical Device Software 12

3.2. Intended purpose and claims

• MDR art 2 Definition (1) Medical Device

• MDR art 2 Definition (12) Intended Purpose
• MDR art 7 Claims
• IMDRF SaMD WG/N12 "Software as a Medical Device": Possible Framework for Risk
Categorization and Corresponding Considerations

The intended purpose and the claims about safety, performance, risks and benefits
determine the qualification and classification of the medical device. In general, it is best
to describe them in a technical way. For example, the device performs a specific therapy,
instead of the device cures the patient from a specific disease. The technical claims
are easier to prove, and curing patients, often requires clinical evidence from a clinical
investigation. When creating an intended purpose, it is advised to use the language
of MDR art 2 (1) of the definition of a Medical Device, to avoid qualification problems.
Moreover, it is advised to use the language of IMDRF SaMD WG/N12 chapter 5 to avoid
classification problems, since the MDCG 2019-11 guidance is based on this section.

For devices with general indications for use that do not specify a disease, condition,
or population (or an anatomical site from which a disease state or population may be
inferred), the indications for use and intended purpose are the same. Such indications for
use are referred to as “tool type” indications for use. Examples of devices with “tool type”
indications for use include devices such as scalpels, which are often indicated for cutting
tissue, or imaging devices, which are often indicated for taking images of the body.

Claims on safety, performance, risks and benefits need evidence see MDR art 7. It is
advised to make a claim matrix, containing the claim, where it is made and where the
evidence is. The Claim Matrix can be placed in the Clinical Evaluation Report. A claim
matrix could look like this:

Table 3 Claim matrix

Claim Where made Evidence

•T
 reatment plan • Brochure • Validation report with analysis of treatment
calculated in • Document identification plan calculated within 2 minutes.
2 minutes number and revision • Document identification number and revision
•D
 evice uses • Website • See Clinical evaluation report evidence for this
state of the art • Document identification claim (which contains analyzed scientifically
algorithms number and revision published articles)

3.3. Qualification

• MDCG 2019-11 Guidance on Qualification and Classification of Software

• MDCG guidance to be published: Borderline and Classification manual
• EU Infographic Is your software a Medical Device?

Qualification is an important step and should always be done before classification. The
guidance MDCG 2019-11 Qualification and classification of software contains a decision
tree to be followed (see figure below), to determine if your software is MDSW.

Medical Devices include devices with the specific medical purpose of prediction and
prognosis of a disease. The MDR introduces an extension of the definition of software as
a medical device. Software devices that might fall under the scope of this definition is
MDSW as a module of a software solution or as an accessory to a Medical Device.

MDR Guide for Medical Device Software 13

 Table 4 MDCG 2019-11 Figure 1: Qualification Steps

Step Remarks
1. L ook if the Software matches the Software definition:
no A set of instructions that processes input data and creates
Not in

Is the product software according

scope

1 output data.
to the definition of this guidance?
2. a) Look if the Software matches the Accessory definition
yes (MDR art 2(2)): An article which, whilst not being itself a
medical device, is intended by its manufacturer to be used
Is the software an annex XVI device, yes together with one or several particular medical device(s)
MDSW MDSW
2a an accessory for a medical device to specifically enable the medical device(s) to be used
according to MDR art 2(2) in accordance with its/their intended purpose(s) or to
specifically and directly assist the medical functionality of the
no medical device(s) in terms of its/their intended purpose(s).
The part or the accessory can be individually CE marked.
Is the software driving or influencing yes b) Look if the Software is driving or influencing hardware. If
2b the use of a (hardware) medical the software is part of hardware, then classification rule 11
device? does not apply as it then falls within the same risk class as
Not covered by the MDR

the device (MDR Annex VIII implementing rule 3.2).

Covered by the MDR

no 3. Look if the Software matches 3.
4. Look if the Software matches 4:
no Is the SW performing an action on *) Software for population and epidemiological studies is
3 data different from storage, archival, not in scope.
communication or simple search? *) Software for educational purposes is not in scope,
provided it is not directed at individual patients, i.e. doesn’t
yes use patient input data to provide patient specific decision
support.
no 5. Look if the Software matches the MDSW ­definition.
4 Is the action for the benefit of
individual patients? Software that is intended to be used, alone or in
combination, for a purpose as specified in the definition of
yes a “medical device” in the Medical Devices Regulation.
no yes
5 Is the software a MDSW according to In other words: does the software create i­nformation for a
the definition of this guidance? medical purpose?
*) regardless of its location: e.g. operating in the cloud,
on a computer, on a mobile phone, or as an additional
functionality on a hardware medical device.
*) regardless of whether the software, in addition, also
drives or influences the use of a (hard-ware) device.

Examples for the Qualification can be found in MDCG 2019-11 and the Borderline and
Classification manual.

The following figure shows Software Modules which have or have not a Medical Device
intended purpose:

Figuur 7 Figure 4 Examples of software modules with intended purpose

Figure 4 Examples of software modules with intended purpose

No Medical Device Medical Device

Intended Purpose Software module Intended Purpose

- Patient information transfer Electronic Patient - Image viewer with diagnostic

or storage Record System functionality
- Medication module

- Patient identification Hospital Information - Indicating high blood pressure

- Patient scheduling System

- Showing and saving pictures Picture Archive - Compare pictures to identify

Communication System disease progression

- Measuring skin tone to Health app - Measuring skin tone to

prevent sunburn prevent cancer

MDR Guide for Medical Device Software 14

Figuur 8 Table 6 CE marking of MDSW with modules
3.4. Classification

• MDR art 2 Definition (4) Active Device

• MDR art 51 Classification of devices
• MDR Annex VIII Classification rules
• MDCG 2019-11 Guidance on Qualification and Classification of Software
• MDCG 2021-xx Borderline and Classification manual (to be published)

3.4.1. Implementing rules

The implementing rules have a huge impact on how a Medical Device needs to be divided
in Modules with or without a Medical Device intended purpose, how to define accessories
and if the CE marking need to take place on the Medical Device level or on the Module and
Accessory level.

Table 5 Implementing rules

Implementing rule Remarks

3.1. A
 pplication of the classification rules shall The intended purpose of the Medical
be governed by the intended purpose of the Device, Module or Accessory determines the
devices. classification. It deserves recommendation to
do the classification both on Medical Device
and on Module / Accessory level, since rule 11
can cause up classification of the hardware,
when the MDSW is classified in its own right.
3.2a.If the device in question is intended to This rule also applies to a Medical Device,
be used in combination with another which is classified on a Module level.
device, the classification rules shall apply
separately to each of the devices.
3.2b. A
 ccessories for a medical device and for Consider the consequences of implementing
a product listed in Annex XVI shall be rule 3.1
classified in their own right separately
from the device with which they are used.
3.3a. S oftware, which drives a device or Consider the consequences of implementing
influences the use of a device, shall fall rule 3.1
within the same class as the device.
3.4. If the device is not intended to be used If there are several classifications possible, the
solely or principally in a specific part of the highest classification applies.
body, it shall be considered and classified
on the basis of the most critical specified
use.
3.5. If several rules, or if, within the same rule, If there are several classifications possible, the
several sub-rules, apply to the same device highest classification applies.
based on the device's intended purpose,
the strictest rule and sub-rule resulting in
the higher classification shall apply.
3.7. A
 device is considered to allow direct The MDCG guidance gives the following
diagnosis when it provides the diagnosis example: Active devices, such as electronic
of the disease or condition in question thermometers and stethoscopes, which include
by itself or when it provides decisive MDSW intended for direct diagnosis may be
information for the diagnosis. classified as class IIa per Rule 10, third indent
since body temperature and heart rate are
considered decisive information for diagnosis
(implementing rule 3.7), where the nature of
the variations of these parameters would not
result in immediate danger to the patient.

MDR Guide for Medical Device Software 15

Applying implementing rules 3.1, 3.2 and 3.3 allow three main variations, how MDSW can
be part of a Medical Device. Further explanation about modules can be found in MDCG
2019-11 chapter 7 Modules. The variations and their consequences can be seen in the
following table:

Table 6 CE marking of MDSW with modules

Variation Consequences

Medical Device with Medical Device modules CE marked Medical Device

• Must meet MDR requirements.
• Must be qualified and classified.
Module Module Module Module
MDSW MDSW MDSW MDSW Medical Device Modules:
• Are driving or influencing the Medical Device.

Device with Medical Device modules CE marked Medical Device modules

• Must be within the intended purpose.
Module Module Module Module • Must meet MDR requirements.
MDSW MDSW MDSW MDSW • Must be qualified and classified.
Non-CE-marked modules:
• Must be outside intended use.
• Must be safe and performing when used in combination
with CE marked modules.

Medical Device with modules and accessories CE marked Medical Device

• Must meet MDR requirements.
Module Module Module Accessory • Must be qualified and classified.
MDSW MDSW MDSW MDSW
Medical Device Accessory:
• Is intended to be used together with one or more Medical
Device(s).
• Must meet MDR requirements.
• Must be qualified and classified in its own right.

3.4.2. Classification rules

The classification rules determine the risk class of a Medical Device or Accessory.
Classification has to be done very accurately, since an incorrect classification has huge
consequences. Too low, might lead to huge fines and force products to be removed
from the market. Too high might lead to additional work, the need for additional clinical
investigations and therefor higher costs.

Classification is based on the intended purpose and the claims of the Medical Device,
Module or Accessory. The intended purpose is compared with the classification rule text.
It is best practice, to do this with all the rules, since there are some hidden surprises. For
example: Rule 8: All implantable devices and long-term surgically invasive devices are
classified as class IIb unless they are active implantable devices or their accessories, in
which cases they are classified as class III. An accessory of an implantable device can also
be MDSW, which is not implanted. By means of rule 8, it can become class III, needing a
clinical investigation. So, the intended purpose should be carefully described, if this could
be the case.

MDD or AIMDD compliant Medical Devices can be placed on the market as long as they
have a valid CE certificate MDR art 120 (3) even if they are up classified under the MDR,
however the QMS needs to conform to MDR art 10 after 26 May 2021. In addition, no
significant changes can be made to the Medical Device after 26 May 2021, as this would
then require CE-marking under the MDR.

It deserves recommendation to do the classification both on Medical Device and on

Module / Accessory level, since rule 11 can cause up-classification of the hardware, when
the MDSW is classified in its own right.

MDR Guide for Medical Device Software 16

Table 6 CE marking of Table 7 Classification rules with modules

Rule Remarks
Rule 1 – 4 Non-invasive devices These rules are in general for non-invasive hardware
devices. These rules have to be considered if the MDSW
is part of the hardware, driving or influencing the
hardware or an accessory to the hardware.
Rule 5-8: Invasive devices These rules are in general for invasive hardware devices.
These rules have to be considered if the MDSW is part of
the hardware, driving or influencing the hardware or an
accessory to the hardware.
Rule 9-13: Active (including software) These rules are for software and hardware devices.
Software is defined as an active device.
Rule 10: Diagnosis or monitoring This rule is about diagnosis or monitoring. These
two terms should not be confused. In most cases the
physician is doing the diagnosis, and the software only
provides the information, which is monitoring.
Rule 11: Software See paragraph 3.4.3 for an extensive explanation.
Rule 14-22 Special rules These rules describe specific situations, for which
additional classification rules are made. These rules are
in general not applicable for MDSW. These rules have
to be considered if the MDSW is part of the hardware,
driving or influencing the hardware or an accessory to
the hardware.

3.4.3. Classification rule 11

MDR annex VIII, rule 11 will often lead to the highest classification for MDSW. Not
applying the MDCG 2019-11 guidance, however, comes at a high price, as shown in Table
1. The text of rule 11 is repeated in this table. For example, according to rule 11, all MDSW
treating or diagnosing cancer (which is critical) is class III. However, under the MDD, in
general, this is class IIb or lower, and sometimes even class I.

To obtain a correct classification, the guidance document MDCG 2019-11 and MDR
annex VIII implementation rule 3.3 should be used. The MDCG 2019-11 guidance is
based on the IMDRF/SaMD WG/N125 guidance, which is the source for the table. The
IMDRF guidance recognizes that most software has an indirect influence on treatment
or diagnosis and that therefore, the classification should be lower. So, software that
drives clinical management (middle column in the table) or software that informs clinical
management (right column), should have a lower risk class. An example coming from the
IMDRF guidance is radiation therapy treatment planning. This software is driving clinical
management of radiation treatment delivery for cancer, which is critical. Applying MDCG
2019-11 puts this software in the middle column in the top row, and thus the classification
is class IIb. It should be noted that IMDRF/SaMD WG/N12 contains a mistake, which is
explained in the note from MDCG 2019-11 Annex III. The N12 document mistakes are in 7.3
Criteria for Category II for i and iii, 7.4 Category III for i and ii examples.

The software in the left column is often part of treating and diagnosing hardware. Here,
implementing rule 3.3a is important, which says software driving a medical device or
influencing the use of a medical device, should fall within the same class as the medical
device, avoiding the problem of rule 11 for hardware containing software.

MDR Guide for Medical Device Software 17

 Figure 5 Classification rule 11
Figuur 9 Figure 5 Classification rule 11

6 1 Rule 11 part “a”

1
MDR Annex VIII: 5 Treat or Diagnose Drive Clinical Inform
Rule 11 Management Clinical Mgt

2 Critical Class III: MDSW providing Class IIb Class IIa

MDCG 2019-11: information to take decisions
Software for diagnosis or therapeutic
Qualification and purposes that may cause death or
Classification an irreversible deterioration of a
person's state of health.
3 IMDRF N12 4 Software driving or influencing
SaMD
hardware see classification rule 3.3a

Class IIb: MDSW providing Class IIa Class IIa

Serious information to take decisions for
diagnosis or therapeutic purposes,
that may cause serious deterioration
of a person's state of health or a
surgical intervention.

Non-serious Class IIa: MDSW providing Class IIa Class IIa

information to take decisions for
diagnosis or therapeutic purposes.

3.5. Requirements related to risk class

Figuur 10 The risk class of a device has consequences for the obligations of a Manufacturer.
4.2 Conformity Assessment route
The major consequences are shown in the table below:

Table 8 Requirements
I related to riskIs,class
Im, Ir IIa, IIb without III with
IIb implantables IIb implantables
Self assessment NB assessment NB assessment NB assessment
Major obligations
Art 10-Quality System Class
Art 10-Quality I
System Class Is, Im, Ir System
ISO 13485-Quality Class IIa System
ISO 13485-Quality Class IIb Class III &
Annex IX: section 1 Annex IX: section 2, 3 Annex IX: section 2, 3 Implantables
& & & &
Quality
SelfManagement
assessment System: Self assessment NBArt. 10 Technical
assessment: NB assessment: Technical Art. 10 &
Technical Documentation Technical Documentation Documentation Annex IX: Documentation Annex IX: ISO 13485
& section 4 section 4
•A
 ssessment of the QMS byLimited the NB-assessment: Annex IX: Annex IX:
Notified Body Technical Documentation section 1 section 2, 3
Annex IX: section 4
Technical Documentation: Annex II, IIIadditional
Specific
procedures Annex IX:
• General Safety and Performance Annexsection
I 5
Requirements checklist
• Risk Management Annex I part section 3
Declaration of conformity
•C
 linical Evaluation Plan / Report Annex XIV part A
• PMCF Plan Annex XIV part B
CE mark CE mark with Notified Body number
•C
 linical Development Plan Annex XIV part A section 1
•C
 linical Investigation (file) (The need for a clinical investigation is determined in the clinical evaluation) Annex XV
• S ummary of Safety and Clinical - Art 32
Performance
• PMS Plan Art. 84
• PMS Report Art. 84 -
•P
 eriodic Safety Update Report - Art. 86
•A
 ssessment of Technical - Annex IX: section 4, only Annex IX: section 4
Documentation by the Notified for Sterile, Measurement
Body or Reusable part
Specific additional procedures - Annex IX:
section 5
MDR Guide for Medical Device Software 5
Declaration of Conformity Annex IV
CE marking of Medical Device Annex V

Note 1: the requirements for the conformity assessments routes for product conformity
verification and type examination are not shown, because of their limited practical use.

MDR Guide for Medical Device Software 18

 04
CE Marking
Figuur 9 Figure 5 Classification rule 11

6 1 Rule 11 part “a”

1
MDR Annex VIII: 5 Treat or Diagnose Drive Clinical Inform
Rule 11 Management Clinical Mgt

4.1.
2 MDCG Introduction
2019-11:
Critical Class III: MDSW providing
information to take decisions
Class IIb Class IIa
Software for diagnosis or therapeutic
ThisQualification and
chapter explains
Classification
the CE marking.purposes
The CE mark
that is adeath
may cause symbolor on MDSW that shows that
an irreversible deterioration of a
the product is allowed according the MDR
person'son beof sold
state health.on the market. In most cases for
3 IMDRF N12
MDSW a Notified Body reviews the technical
4 Softwaredocumentation
driving or influencing and audits the QMS before
SaMD
the CE can be applied. A Notified Bodyhardware
is a technical competent
see classification rule 3.3a organization appointed

by the Competent Authority (the national government)

Class IIb: MDSW providingand the European Class IIa Commission.
Class IIa
Serious and audit
When the Notified Body review information to take decisions for
are successful, then the MDSW is CE certified
diagnosis or therapeutic purposes,
and is the Manufacturer allowed to sell thatthe
mayproduct.
cause seriousThe risk class determines the detailed
deterioration
of a person's state of health or a
certification steps, which is called a conformity assessment route.
surgical intervention.

4.2. Conformity Assessment

Non-serious Class IIa:route
MDSW providing Class IIa Class IIa
information to take decisions for
diagnosis or therapeutic purposes.
Depending on the risk class of a Medical Device you can determine what is required to
obtain your CE Mark, this is called Conformity Assessment route. There are multiple
Conformity Assessment routes, but most are not practical for MDSW. Only the most
important Conformity Assessment Routes per risk class are given below:

Figuur 10
4.2 Conformity Assessment route
Figure 6 Conformity Assessment routes

I Is, Im, Ir IIa, IIb without III with

IIb implantables IIb implantables
Self assessment NB assessment NB assessment NB assessment
Art 10-Quality System Art 10-Quality System ISO 13485-Quality System ISO 13485-Quality System
Annex IX: section 1 Annex IX: section 2, 3 Annex IX: section 2, 3
& & & &
Self assessment Self assessment NB assessment: Technical NB assessment: Technical
Technical Documentation Technical Documentation Documentation Annex IX: Documentation Annex IX:
& section 4 section 4
Limited NB assessment:
Technical Documentation
Annex IX: section 4
Specific additional
procedures Annex IX:
section 5

Declaration of conformity

CE mark CE mark with Notified Body number

Risk Class I, the manufacturer has to do the following:

• Self-assessment of Technical Documentation (Annex I) and QMS (Art. 10 and Annex II &
III).
• Draw up a Declaration of conformity (MDR art 19 and Annex IV).
• Perform a registration at Farmatec (also called CIBG and NOTIS).
- Submit the product information showing the intended use and the risk classification
of the Medical Device.
- Provide a Declaration of Conformity (MDR art 19 and Annex IV).

MDR Guide for Medical Device Software 5

MDR Guide for Medical Device Software 19

Risk Class Is (sterile device), Im (measurement device), Ir (reusable device): These risk
classes are not likely applicable for MDSW, with the exception of Class Im. In addition to
the activities mentioned under risk class I, also a Notified Body is needed who performs
the following activities:
• Assessment of Technical Documentation concerning measurement function, sterility or
reusability (Annex I).
• Provide CE certificate for the Medical Device for the measurement function, sterility or
reusability.

Risk Class IIa, IIb without IIb implantables: The difference between risk class IIa and IIb is
not that large. However, for risk class IIb, the Notified Body oversight is more intense. The
Notified Body has to do the following:
• Assessment of QMS (Annex IX).
• Assessment of Technical Documentation of a representative device for each category of
devices (for Class IIa: MDR art 52 Para 6).
• Assessment of Technical Documentation of a representative device of each generic
device group (for Class IIb: MDR art 52 Para 4).
• Provide CE certificate for the Medical Device.
• The manufacturer has to draw up a Declaration of conformity (MDR art 19 and Annex IV).

Risk Class III and IIb implantables: This risk class has two phases. A Clinical Investigation
phase with oversight of the Competent Authority and a Pre-Market phase, with oversight
from the Notified Body. This split in responsibilities causes a major problem. According
to Annex VII, a Notified Body is not allowed to give consultancy to a manufacturer.
The Notified Body reviews if there is sufficient Clinical Evidence, however currently the
Notified Body is not allowed to do that review before the Clinical Investigation phase.
Class III MDSW manufacturers are strongly advised to discuss this issue at the start of the
developing of a new MDSW, both with the Competent Authority and Notified Body (what
their position is, and how that can be solved).
• In the clinical phase, the Competent Authority has to do the following:
- Review Clinical Investigation Safety & Ethics.
- Review Clinical Development Plan / Strategy.
• In the clinical phase, the European Commission has to do the following:
- Send selected product group dossiers to expert panel for scrutiny procedure (Note the
Notified Body sent the file to the European Commission).
• In the clinical phase, the Expert Panel has to do the following:
- Review Clinical Investigation.
- Review Clinical Development Plan / Strategy.
- Give binding advise to the notified body.
• In the pre-market phase, the Notified Body has to do the following:
- Assess QMS (Annex IX).
- Assess Technical Documentation and QMS (Annex II & III).
- Assessment of Technical Documentation (MDR art 52 (3)).
- Provide CE certificate for the Medical Device.
- The manufacturer has to draw up a Declaration of Conformity (MDR art 19 and Annex IV).

4.3. Competent Authority and MDCG

The Competent Authority are the departments of the Ministry of Health (VWS in The
Netherlands) that execute the MDR. In the Netherlands it is arranged in the following
manner:
• The ministry of VWS is responsible for implementing the MDR in Dutch legislation
and represents the Netherlands in the MDCG. VWS also designates the Dutch notified
bodies.
• The Health and Youth Care Inspectorate (Inspectie Gezondheidszorg en Jeugd (IGJ)) is
responsible for the medical devices on the Dutch market and inspects manufacturers
and oversees the vigilance reporting and field corrective actions called Market
Surveillance (this is not the same as Post Market Surveillance). The IGJ also supervises
the Dutch notified bodies.

MDR Guide for Medical Device Software 20

• CCMO coordinates the clinical investigations in The Netherlands.
• RIVM provides scientific support to the above-mentioned authorities in The Netherlands.

The MDCG is a council with representatives from all the Member States of the European
Union. Swiss and some other countries have also a seat in the MDCG, but do not have a
vote. The MDCG together with the European Commission develop the MDCG guidance
and execute oversight on the implementation of the MDR. An example of the oversight is
the Joint Assessment Teams that accredit the Notified Bodies.

4.4. Notified Body

The Notified Bodies perform the CE marking audits for the QMS and the Technical
documentation reviews, depending on the requirements of the Conformity Assessment
routes. The audit and review activities do follow strict requirements, checked by the
Competent Authorities. The Notified Body assessment has the following elements:
• ISO 13485 stage 1 audit (only class IIa, IIb and III)
- To verify the readiness of the organization’s QMS for a stage 2 audit including:
› A review of the QMS documentation.
› A review of the status and understanding regarding requirements of the standard.
› Determination of the QMS scope.
› Evaluation of the planning and performance of internal audits and the
management review process
• ISO 13485 stage 2 (certification) (only class IIa, IIb and III)
- To evaluate the implementation and effectiveness of the QMS. Typically, there are
3 months between stage 1 and 2, allowing to gather evidence of implementation
and effectiveness of the QMS processes. The Notified Body will review all processes
and determines how the manufacturer has implemented the MDR and ISO 13485
requirements.
• Technical documentation review (class Im, Is, Ir, IIa, IIb and III)
- Prior to the ISO 13485 stage 2 certification audits, all relevant technical
documentations are assessed by a team of experts, involving at least product, clinical
and biocompatibility experts when applicable. They will evaluate, if requirements
according MDR annex I, II and III including clinical evaluation and related documents
and activities, such as PMS, PMCF and if applicable PSUR and SSCP have been
fulfilled.
- For class Im only the measurement aspect, Is only the sterilization aspect and Ir only
the reusable aspect of the technical documentation is reviewed.
• Nonconformities.
- In general, some nonconformities will be raised during each audit and technical
documentation review. These nonconformities need to be resolved and closed before
the certification process can finalized.

Notified Bodies perform other MDR activities like reviewing System Security Certified
Practitioners (SSCPs) and registering information in EUDAMED.

Obtaining a Notified Body is not easy. The search should start early in the development
process. Notified Bodies can be found in the NANDO database at the European
Commission website from DG SANTE. The NANDO database shows the accredited scope
of a Notified Body, which indicates if the Notified Body is allowed to accept the Medical
Device for certification.

The Notified Bodies are overloaded and do a strict customer pre-selection. They only
accept good quality customers. A good well-resourced MDR project plan and a good setup
of the Technical documentation provides evidence of being a good customer.

MDR Guide for Medical Device Software 21

4.5. Declaration of Conformity and CE Marking

• MDR art 5 Placing on the market

• MDR art 19 Declaration of Conformity
• MDR art 20 CE marking of conformity
• MDR annex IV Declaration of Conformity
• MDR annex V CE Marking of conformity

When the conformity assessment is ready, the manufacturer can make a Declaration
of Conformation. This is a document that the manufacturer declares that its device and
quality system meet the requirements of the MDR. For class I devices the manufacturer
does the conformity assessment on his own, which is called a self-assessment. For class
IIa and higher Medical Devices, the Notified Body makes this assessment and provides
a CE certificate as results of this assessment. After the Declaration of Conformity the
Manufacturer can place the CE mark on the Medical Device and then the Medical Device
can be sold in the EU.

Where software is submitted on a medium it should be properly CE marked. Where the

identification of the software is displayed in the GUI, place the CE mark close to the device
identification.

4.6. Free sales certificates

• MDR art 60 Certificate of free sale

• Medtech Europe Impact of changes under the new EU Medical Devices Regulation
(EU) 2017/745 to in-ternational registrations

To export a Medical Devices outside of the European Union in general a Free Sales
Certificate and related paperwork is needed as required by the country of destination.
Most manufacturers outsource this to a professional service organization, which often
saves a lot of money, time and frustration. A typical list of those documents looks like
this:

• Certificate of free sales, this can be obtained via Farmatec.

- Declaration of Conformance.
- CE certificate of a Notified Body for Class I measurement, sterile and reusable, Class
IIa/b and Class III.
• Certificate of Origin.
• Digital or physical stamp Chamber of Commerce.
• Translation by a Sworn Translator.
• Notarization of documents.
• Apostille or legalization of signatures.
• Legalization of documents at the Ministry of Foreign Affairs.
• Embassy of country of destination approval.

MDR Guide for Medical Device Software 22

05
Technical Documentation

5.1. Introduction
Chapter 5 describes the contents of the Technical Documentation. The Technical
Documentation contains the evidence that is created during the development process,
so that the Notified Body can review the quality of the MDSW and if all related MDR
requirements are fulfilled. The Manufacturer uses a GSPR checklist, to show where the
evidence for the Software Development (Life Cycle), Risk Management, Clinical Evaluation
and other processes can be found in the Technical Documentation.

5.2. Technical Documentation (on Post-Market Surveillance)

• MDR Annex II: Technical Documentation

• MDR Annex III: Technical Documentation on Post-Market Surveillance
• Recommendation NB-MED/2.5.1/Rec5: Technical Documentation
• GHTF-SG1-N011R17 Summary Technical Documentation for Demonstrating
Conformity to the Essential Princples of Safety and Performance of Medical Devices
(STED)

The term Technical Documentation (or technical file) refers to all the documents that
a medical device manufacturer has to retain. The requirements for those documents
are given in MDR annex II and III. The Technical Documentation of MDR Annex II. NB-
MED/2.5.1/Rec5: Technical Documentation and GHTF-SG1-N011R17 Summary Technical
Documentation (STED) give guidance how to setup the Technical Documentation,
however this guidance has aged significantly.

The Technical Documentation for a device has to be created and maintained (MDR art 10
(4)). The Technical Documentation has to be supplied to the Competent Authorities when
requested. A copy has to be kept by the Authorized Representatives (MDR art 11 (3)). The
Person responsible for regulatory compliance has to ensure the Technical Documentation
is kept up to date (MDR art 15(3)). The Notified Body reviews the Technical Documentation
(MDR annex IX chapter II). To facilitate all these uses that the technical documentation
is structured well as described in MDR annex II and III. Strict traceability is expected
between the Technical Documentation, the GSPR checklist and the related documents.
The related documents have to be immediately available for the Notified Body, so either in
hardcopy or in electronic file format, such as a pdf. Strict requirement traceability is also
expected between safety, performance requirements and claim, user requirements, system
requirements, software / functional requirements, risk analysis, risk controls and tests.

For the MDR annex II documents the GSPR checklist of annex I have to be used, to check
if all the (General) Safety and Performance Requirements are met and the evidence is in a
corresponding document. For the Technical Documentation on Post-Market Surveillance,
such a checklist does not exist. It is good practice, to create the Technical Documentation
at the start of a development project and make empty references for the documents

MDR Guide for Medical Device Software 23

needed. Otherwise completing the documentation at the end of a development project
can be a huge task.

The technical documentation (MDR annex II) gives the details what has to be
documented. In addition, technical documentation for the Software Development Life
Cycle, Cybersecurity and Interoperability have to be added. The technical documentation
consists of the following elements:
• Device description and specification, including variants and accessories
- Device description:
› Name.
› UDI.
› Patient population and their medical condition.
› Principle of operation.
› Qualification of the medical device.
› Classification of the medical device.
› Explanation of innovations.
› Description of accessories and, if applicable, system modules / components.
› Configurations and variants.
› Parts and components.
› Raw materials and elements with human body contact.
› Technical specifications.
- Reference to previous and similar generations of the device.
• Information to be supplied by the manufacturer:
- Device and packaging label and instructions for use.
• Design and manufacturing information:
- Description of the development process.
- Description of manufacturing processes.
- Software Validation of development tools.
- Manufacturing validations, monitoring and final device testing.
- Identification of all suppliers and subcontractors used for development,
manufacturing, hosting, installation and service activities.
• General safety and performance requirements (annex I):
- Identification of applicable GSPRs in MDR annex I.
- Evidence of conformity with the GSPRs, including:
› Methods used to demonstrate conformity.
› Applicable standards, Common Specifications and other requirements.
› Links to documents demonstrating conformity.
• Benefit-risk analysis and risk management:
- Benefit-risk analysis MDR Annex I (1,8), where benefits outweigh the risks and the
benefit-risk ratio meets the State of the Art and the risks are reduced as far as
possible and acceptable.
- Risk Management MDR Annex I (3), as required in ISO 14791.
• Device verification and validation:
- Pre-clinical data:
› System requirements test plan and report.
- Clinical data:
› Clinical evaluation plan and report.
› PMCF plan and report.
- Description of combination/configuration with connected devices.

The technical documentation on post-market surveillance (annex III) consists of the

following elements:
• Post-market surveillance plan.
• Post-market surveillance report (class I).
• Periodic safety update report (PSUR) (class IIa, IIb, III).

MDR Guide for Medical Device Software 24

5.3. General Safety and Performance Requirements (GSPR)

5.3.1. GSPR checklist

• MDR Annex I: General Safety and Performance Requirements

• COCIR Recommendation Applicability of EHSR of the Machinery Directive (2006/42/
EC) to Medical Devic-es
• Medtech Europe: The use of state-of-the-art standards in the absence of harmonized
standards under the IVD and Medical Devices Regulations (IVDR/MDR)

The GSPR in MDR Annex I stands for General Safety and Performance Requirements.
These requirements should be met by your MDSW if they are applicable. It is good
practice to put the GSPR requirements in a checklist, as can be seen below. In this
example for clarity, not the complete text under requirement is shown. In the second
column it is shown if the requirements are applicable (A) or not applicable (NA). If it is
applicable, then in the last column the evidence has to be given. For instance, the risk
management report. Normally the reference to this report is given, which is part of
the technical documentation as mentioned in MDR Annex II. If the requirement is not
applicable, then in this column a justification has to be given, why the requirement is
not applicable. In the middle column common specifications, (harmonized) standards
or guidance should be given, for which the evidence in the last column is shown. The
evidence is part of the Technical Documentation see MDR Annex II.

Table 9 GSPR checklist

# Requirement A Common specification, standard, Reference or Justification for not applicable

N/A sub clause or ref. {additional notes}
1 Performance and safety A - ISO 14971 - Risk management report
{Include the full text - MEDDEV 2.7.1 rev 4 - Clinical evaluation report
here from the annex.} - IEC 82304-1 - Verification & Validation report
- ISO 60601-1-6 - Summary of safety and clinical
- {MDCG SSCP} performance
2 Reduction of risks A - ISO 14971 - Risk management report
3 Risk management A - ISO 14971 - Risk management report
system
4 Risk control measures A - ISO 14971 - Risk management report
and residual risks
5 Risks related to use A - ISO 14971 - Usability specifications
- IEC 62366-1 Application of - Usability verification (formative evaluation)
usability engineering to medical - Usability validation (summative evaluation)
devices

In case of medical electrical

equipment also:
- IEC 60601-1-6 Medical electrical
equipment: Usability
6 Device lifetime A
7 Packaging, transport, A - ISO 11607-1 Not always applicable for MDSW}
storage - ISO 11607-2
- EN 868-5
8 Positive benefit - risk A
ratio
9 Devices without a N/A
medical purpose
10 Chemical, physical and N/A
biological properties
11 Infection and microbial N/A
contamination

MDR Guide for Medical Device Software 25

 # Requirement A Common specification, standard, Reference or Justification for not applicable
N/A sub clause or ref. {additional notes}
11.7 Packaging systems for A - System Requirements Specification
non-sterile devices - Verification Report
12 Devices incorporating N/A
a medicinal product,
substances absorbed or
locally dispersed
13 Devices incorporating N/A
materials of biological
origin
14 Construction of devices A -M  DCG 2019-16 Guidance on
and interaction with Cybersecurity for medical
their environment devices
14.2d Software and IT A - IEC 60601-1 Requirements for {This clause is explicitly addressing risks for
environment interaction medical electrical equipment software at the system and network level.
risks - IEC/ISO 80001 Risk This includes consideration of cybersecurity
management for IT networks and network potential risks and information
incorporating medical devices to the user for IT networks that cannot be
- IEC 82304-1 Health software validated by the manufacturer.}
15 Devices with a
diagnostic or measuring
function
16 Protection against N/A
radiation
17 Electronic A
programmable systems
and software
18 Active devices and A {Software is active}
devices connected to
them
19 Particular requirements
for active implantable
devices
20 Protection against
mechanical and thermal
risks
21 Protection against
the risks posed to
the patient or user
by devices supplying
energy or substances
22 Protection against the
risks posed by medical
devices intended for use
by lay persons
23 Label and instructions A - E N 1041: Information supplied - Labels
for use by the manufacturer of medical - Instructions for use (clinician and patient)
devices - Service manuals
- ISO 15223-1: Medical devices – - Installation manuals,
Symbols to be used with medical - Marketing material
labels, labelling and - Website
- information to be supplied –
Part 1: General requirements

5.3.2. Applicable Standards

• MDCG 2021-5 Guidance on standardization for medical devices

In preparation of the GSPR checklist a search is performed which Regulations, (Harmonized)

Standards, Common Specifications and other Guidance which is applicable for developing the
MDSW. These are often called the Applicable Standards. In the GSPR checklist, the Applicable
Standards are placed in the column “Common specification, standard, sub clause or ref.”

MDR Guide for Medical Device Software 26

When a harmonized standard is followed, then compliance with the MDR is assumed
for the scope of the harmonized standard. Following a Harmonized Standard is
“voluntary”, however in practice they are almost always followed. A Common Specification
is comparable to a harmonized standard. But, it is required to follow a Common
Specification. Often it is recommended to follow a standard, but it is not required.

If the MDSW is part of a hardware device, then also the Machine Directive is applicable.
The COCIR Recommendation Applicability of EHSR of the Machinery Directive (2006/42/
EC) to Medical Devices, explains how to fill out the EHSR requirements of the Machinery
Directive.

Software that contains hardware also leads to additional requirements. Some important
examples are:
• Machine Directive which contains requirements if your software is embedded in
hardware.
• REACH, ROSH, and others which contain environmental regulations.
• Ecodesign Directive for design and energy saving, which contain environmental
regulations.
• Batteries Directive which contains regulations for batteries.
• Packaging Directive which contains packaging regulations.

MDSW always functions in an environment, the interaction with the environment often
leads to additional requirements. Some important examples are:
• General Data Protection Regulation (GDPR) containing privacy requirements if you
gather Personal Data in Dutch called AVG.
• Radio Equipment Directive (RED) (new release under development) containing
requirements for Cyberse-curity.
• IVDR contains requirements if your device is also an In Vitro Diagnostic device
according to the IVDR.

Software often needs to communicate and share data with its environment
(interoperability), like standards, as:
• HL-7 standards contain requirements for transfer of clinical and administrative data.
• DICOM standard contains requirements for the communication and management of
medical imaging infor-mation.
• HCIM (Health and Care Information models) in Dutch called ZIB’s
(ZorgInformatieBouwstenen). A ZIB defines the structure of care information in
a certain situation, to facilitate that care providers can share information. Nictiz
coordinates the development and usage of the ZIB’s. Nictiz is the national competence
center for electronic exchange of health and care information.
• Certification of certain elements of interoperability, like sharing information about
minors is implemented in Dutch legislation.

5.4. Software development life cycle

• MDR Annex I: 17.1 Repeatability, Reliability and Performance

• MDR Annex I: 17.2 State of the Art, Software Development Life Cycle, Risk
Management, (Cyber)security and Verification and Validation
• MDR Annex I: 17.3 Mobile platforms
• MDR Annex I: 17.4 Hardware, IT networks, (Cyber)security
• IEC 62304 MDSW development process
• IEC 82304-1 Health software requirements for product safety
• IEC 60601-1 Medical electrical equipment requirements for safety and performance
• HL7 Consumer Mobile Health Application Functional Framework

MDR Guide for Medical Device Software 27

Figuur 11
5.4 Software development life cycle standards
Figure 7 Software development life cycle standards

Health Software MDSW

SW4& HW

IEC 82304-1 IEC 60601-1

Requirements Requirements

SaMD (SW only)

IEC 62304
Life Cycle

IEC 62366-1 IEC 60601-1-6

Usability Usability

A software development process has to be implemented for the development of MDSW

independent of the methodology followed like Agile or Waterfall. The standards describe
Figuur 12
the5.5.2
development process
Risk management and the deliverables. The following standards are to be
relations
considered for the software development life cycle and for usability:
Post Market Surveillance
• IEC 62304 MDSW – Software Life Cycle Processes: This standard is expected to be
Reportable incidents Quality data:
followed for all software development in addition to ISO
and side-effects 13485
Can the devicefor the QMS. Note:
be improved?
According to ISO 14971 risks should be reduced as far as possible which is more
restricting than IEC 62304 Amendment 1, so here ISO 14971 should be applied.
• IECClinical
82304-1 Health software –Risk
Evaluation General
Management requirements forPost Market safety:
product
Follow Up
Clinical This standard
is for stand-alone health apps or clinical information systems and can be used in
(Claimed) benefits: Suitable indicators and Clinical evidence:
addition
Positive to IEC
impact 62304 for MDSW
on health? thresholdifvalues
applicable.
for PMS The standardSufficient?
also describes higher-level
requirements such as security aspects.
IEC(Claimed)
• Positive
60601-1 benefits:
Medical
impact on
Residual risk and known
health? electrical equipment
side-effects
Safety: New emerging risks
– Part 1: General
for B-R ration requirements
or unknown side-effects? for safety,
including essential performance: This standard is for MDSW integrated in electronic
(Claimed) benefits:
equipment and can be used in Potential
addition acceptance
to IEC 62304 for Misuse
MDSW / off-label use:
if applicable.
Positive impact on health? criteria Correct intended purpose?
• IEC 62366-1 is usability for software and IEC 60601-1-6 is for MDSW integrated in
(Claimed) equipment
electronic benefits: and can be used in addition to IEC 62366-1 State of the if Art:
applicable.
Positive impact on health? Changed?

Full documentation and traceability of the deliverables is expected, to pass the CE

marking process. Therefore, the development process should be in place from the start of
the project, which requires a high level of discipline. To help with this it is common to use
specialized software development software, despite the high cost.

5.5. Risk management

5.5.1. Introduction

• MDR Annex I (1) Acceptable risk

• MDR Annex I (2) Risk reduction
• MDR Annex I (3) Risk Management
• MDR Annex I (4) Risk Controls
• ISO 14971 Application of risk management to medical devices
MDR Guide for Medical Device Software 6
• IEC/TR 80002-1 Guidance for applying ISO 14971 to software
• NPR 5326 Risk management during development and maintenance of custom
software (Dutch)

ISO 14971 describes a systematic approach to risk management for medical devices. IEC/
TR 80002-1 gives guidance for applying ISO 14971 to software. The goal of ISO 14971 is
to obtain a safe medical device, therefore:

MDR Guide for Medical Device Software 28

 • There are no unacceptable risks.
• There is a positive benefit - risk ratio, which is analyzed in the clinical evaluation.

Please note ISO 14971 is for risks related to safety and performance. Security risks are
discussed in the paragraph about cyber security.

5.5.2. Risk Management Plan

ISO 14971 requires a risk management process for the entire product life cycle. This
includes planning and execution of all relevant tasks, activities, procedures, and
responsibilities both during product development and when the product is placed on the
market. This also includes design changes, new risks, changes in the benefit - risk ratio,
etc. To obtain such information, a post-market surveillance system is needed.

The risk management process is described in the risk management plan:

Figuur 11
• 5.4
Risk analysis.
Software development life cycle standards
• Risk assessment.
• Risk control.

Health Software MDSW

A risk management plan defines the acceptance criteria: a device is sufficiently safe
when the benefits outweigh the risks.SWThe risk - benefit ratio is evaluated in the clinical
4& HW
evaluation report. However, the risk - benefit ratio can change over time. Risks that were
IEC 82304-1 IEC 60601-1
acceptableRequirements
in the past do not have to be acceptable in the future.
Requirements

Risk Management contains the mitigations for safety risks found in literature, vigilance
SaMD (SW only)
and regulatory (e.g. MAUDE) databases for own or similar/benchmark devices. The risk
management IECplan
62304derives an acceptable benefit - risk ratio from the clinical evaluation,
based on: Life Cycle
• Consideration of the state of the IEC
IEC 62366-1 art.60601-1-6
• Consideration of product-relevant safety
Usability Usabilitystandards or common specifications.
• Comparison with similar / benchmark devices.
• Analysis of data from clinical evaluations.

The risk management plan is related to the clinical evaluation, PMS and PMCF:
Figuur 12
Figure
5.5.2 8 Risk
Riskmanagement plan relation to Clinical Evaluation, PMS and PMCF
management relations

Post Market Surveillance

Reportable incidents Quality data:
and side-effects Can the device be improved?

Clinical Evaluation Risk Management Post Market Clinical

Follow Up
(Claimed) benefits: Suitable indicators and Clinical evidence:
Positive impact on health? threshold values for PMS Sufficient?

(Claimed) benefits: Residual risk and known Safety: New emerging risks
Positive impact on health? side-effects for B-R ration or unknown side-effects?

(Claimed) benefits: Potential acceptance Misuse / off-label use:

Positive impact on health? criteria Correct intended purpose?

(Claimed) benefits: State of the Art:

Positive impact on health? Changed?

5.5.3. Risk analysis, evaluation and control

Risk analysis and evaluation contain the following steps:

• Define risk acceptance criteria.

MDR Guide for Medical Device Software 29

• D
 etermine the hazards of a product, i.e. those related to the intended use of the
product.
• Estimate risks as a combination of severity and probability.
• Decide whether risks are acceptable.
• Checking and implementing risk control measures.
• Identify new risks and decide whether they are acceptable.
• Determine residual risk and decide whether this appears justifiable.

5.5.4. Risk control

Risk control measures can reduce risks. These are:

• Integrated safety through design.
• Protective measures in the medical device itself or in the manufacturing process.
• Safety information, however in general, this is considered not to reduce risk.
The implemented risk control measures need to be verified and the residual risk assessed.
The individual and overall residual risk needs to be acceptable.

5.5.5. Risk management report

Prior to release for commercial distribution of a medical device, the manufacturer shall
carry out a review of the risk management process. This review shall at least ensure that:
• The risk management plan has been appropriately implemented.
• The overall residual risk is acceptable.
• Appropriate methods are in place to obtain relevant production and post-production
information.

5.6. Clinical Evidence

5.6.1. Introduction

Clinical Evaluation:
• MDR art 61 Clinical Evaluation
• MDR Annex XIV part A Clinical Evaluation
• MDCG 2020-13 Clinical evaluation assessment report template
• MDCG 2020-6 Guidance on sufficient clinical evidence for legacy devices
• MDCG 2020-5 Guidance on clinical evaluation – Equivalence
• MDCG 2019-9 Summary of safety and clinical performance
• (Meddev 2.7. rev 4 Clinical evaluation according the MDD; this document still contains
valuable infor-mation)

MDSW Clinical Evaluation:

• MDCG 2020-1 Guidance on clinical evaluation of MDSW
• IMDRF SaMD WG/N41 Software as a Medical Device (SaMD): Clinical Evaluation
• IMDRF SaMD WG (PD1)/N41R3 Software as a Medical Device (SaMD): Clinical
Evaluation (Proposed Docu-ment)

Clinical Investigation:
• MDR art 61 (4-6) Clinical Investigation
• MDR art 62 - 82 Clinical Investigation
• MDR Annex XV Clinical Investigations
• MDCG 2020-10 Guidance on safety reporting in clinical investigations
• MDCG 2021-6 Questions & Answers regarding clinical investigation
• ISO 14155 Clinical investigation of medical devices for human subjects – Good
Clinical Practice

MDR Guide for Medical Device Software 30

Every Medical Device must have sufficient clinical evidence and is therefore seen as the most
important element to get market access. The clinical evaluation is a scientific approach
to create that evidence and has a long list of detailed requirements in the MDR and the
applicable guidance’s. The clinical evaluation is strictly reviewed if it meets the requirements.
For this the MDCG guidance for Clinical Evaluation Assessment Report is used.

To bring a Medical Device on the market, there must be evidence that the device is safe,
and that the device is doing, what it should do. For this evidence is needed, which consist
of two parts. Technical Evidence, coming for instance from testing and clinical evidence,
which is coming from the Clinical Evaluation Report.

The clinical evaluation is a systematic and scientific analysis process. How to do this
process is described in the MDR Annex XIV part A and in the guidance Meddev 2.7. rev 4.
For the clinical evaluation clinical data is gathered for the own device or for look-a-likes
which are called equivalent devices. Clinical data can come from clinical investigations
and post-market clinical follow up studies or post market surveillance studies. When
the clinical data is analyzed, the conclusions are called clinical evidence. When possible,
clinical evidence maybe replaced by technical evidence, for class IIb devices or lower (see
MDR art 61(10)). For implantables and class III devices always clinical evidence need to be
available, and often clinical investigations according to MDR art 61 (4-6).

The clinical evaluation aims to examine and evaluate clinical data to verify the clinical
safety and performance of the medical device. The results of the clinical evaluation
are used to assess whether the risks associated with the use of the medical device are
acceptable in relation to the expected benefit. The manufacturer must keep the clinical
evaluation up to date throughout the entire life cycle of the product, by repeating the
literature study, and doing post market surveillance. He must update the PMCF assessment
report for Class III and implantable medical devices annually. For lower class devices there
must be at a minimum a plan for PMCF studies Art. 61 (11) and Annex XIV Part B).

In the clinical evaluation it is assessed whether there is sufficient clinical evidence for the
safety and the performance of the device. At a minimum a literature study for the Medical
Device in clinical practice has to be performed. If there is still insufficient Clinical Evidence
or the device is risk class III, then a Clinical Investigation needs to happen. The Clinical
Evidence is put in the Technical documentation.

The results of the clinical investigation needs to be reported in EUDAMED for implantables
and class III devices in a Summary of Safety and Clinical Performance. And for Class IIa
and higher devices also in a Periodic Safety Update Report.

5.6.2. Clinical Evidence documentation

The overall documentation related to the clinical evaluation is getting more complex
according to EU MDR. It requires the following documents:
• Clinical Evaluation Plan (CEP, Annex XIV, Part A, 1.) describing the procedure for clinical
evaluation to demonstrate the benefit - risk ratio based on the state of the art.
• Clinical Evaluation Report (CER, Art. 61 (12)).
• Clinical Development Plan (CDP, Annex XIV Part A 1a & 1d).
• Clinical Investigation Plan (CIP, Annex XV 3).
• Post-Market Clinical Follow-up (PMCF) plan (Annex XIV, Part B) or a justification as to
why a PMCF is not applicable (outlined in the PMS plan).
• PCMF evaluation report (annual update) for class III and implantable devices (Art. 61(11),
Annex XIV).
• Summary of Safety and Clinical Performance (SSCP) for class III and implantable devices
(Art. 32 and 61).
• Periodic Safety Update Report (PSUR) for classes IIa (biannually update), IIb (annual
update) and class III (annual update) devices (Art. 86).
• Clinical Evaluation Assessment Report (CEAR, Annex VII section 4.6, to be compiled by
the notified body).

MDR Guide for Medical Device Software 31

Table 10 Clinical Evaluation related documentation

MDR risk Clinical Clinical Clinical Post Market Post Market Summary
class Evaluation Development Investigation Clinical Clinical of ­Safety
Plan ­Follow-Up Follow-Up report and ­Clinical
plan ­Performance
Justification or Justification or
Class I √ √ Clinical Investigation √ PMCF report -
required required
Justification or Justification or
Class IIa √ √ Clinical Investigation √ PMCF report -
required required
Class IIb Justification or Justification or
without √ √ Clinical Investigation √ PMCF report -
implantables required required
Class III Justification or
with IIb √ √ √ √ PMCF report √
implantables required

The clinical evaluation report (CER) compiles the conclusions of the clinical evaluation.
In addition, the manufacturer must provide a publicly available “Summary of safety and
clinical performance” (Art. 32) for certain high-risk devices. The notified body in turn
documents the results of the clinical evaluation assessment in the clinical evaluation
assessment report (CEAR). In the case of certain high-risk devices, the expert panel,
the competent authorities, the authority responsible for notified bodies and the EU
Commission have these documents at their disposal. The manufacturer commits himself
to the collection of post-market surveillance data in the PMS plan. The periodic safety
update report (PSUR) summarizes this data and contain among others also the main
findings of the post-market clinical follow-up (PMCF). Notably, the EU MDR does not
say something about the frequency of clinical evaluation updates. MEDDEV 2.7/1 Rev. 4
includes such information.

5.6.3. Pre-Clinical, Clinical Data and MDR art 61(10)

Clinical data is any “information concerning safety or performance that is generated from
the use of a device” (Art. 2 (48)). It can come from the following sources:
• Clinical investigation of the device concerned or of an equivalent device.
• Clinical experience with the device concerned or an equivalent device.
• PMCF.

Manufacturers can use clinical data from post-market surveillance (e.g. vigilance data)
as well as results from PMCF studies as additional sources for clinical evaluation. For
this reason, some manufacturers have already started to collect data for their devices
from other markets such as the US. This includes data from Investigator Initiated Studies
(IIS). Whether these data are sufficient to demonstrate the performance, clinical safety
and clinical benefit of a device depends on the quality and significance of the data. The
manufacturer must conduct clinical studies (e.g. PMCF studies) if the available clinical
data is insufficient. Manufacturers should link and keep up to date risk management data,
quality management system and clinical evaluation procedures on a regular basis.

Note that pre-clinical and clinical data must be part of the technical documentation
(Annex II (6.1.)) including:
• Test results.
• Test design and protocols (in the case of software the verification and validation.
• Clinical evaluation report / plan.
• PMCF plan / evaluation report.

Where possible clinical performance study data should be obtained to complement the

MDR Guide for Medical Device Software 32

clinical evidence. If non-clinical testing method data is used instead of clinical evidence
this should be adequately justified according to MDR art 61 (10). This is also applicable for
MDR high risk devices, however the requirement for Clinical Investigation in MDR art 61
(4) remains.

5.6.4. Clinical Evidence

• Clinical Evidence introduction

- The key concept of the MDR is “sufficient clinical evidence” related to MDR art 2
definition (51) about “clinical evidence” and MDR art 61.1 about “clinical evaluation”.
Using these two references, the key concept can be interpreted in the following way:
› Clinical evidence is based on clinical data, which is analyzed in a clinical evaluation.
› Sufficient (level of clinical evidence) is determined by the manufacturer so that a
qualified assessment (MDR art 2 definition (51)) can determine that a device is safe,
performing and can achieve its intended benefits based on the intended purpose.
› The assessor of the manufacturer must be qualified (MDR art 2(51)). In addition,
also the Notified Body needs to have a qualified assessor (MDR Annex VII 3.2.4) to
analyze whether the presented evidence is sufficient.
- The assessor of the Manufacturer plays an important role. Therefore, it is preferred
that the assessor is an experienced and practicing physician if possible. This avoids a
difficult discussion with the Notified Body or the Competent Authority if the assessor
is qualified enough.

• Clinical Evidence acceptance criteria

- The following table gives an overview of the acceptance criteria for clinical evidence:

Table 11 Clinical Evidence Element

Clinical Evidence Element Acceptance criteria (justify the level of clinical evidence)
State of the Art MDR art 61(3c) A literature search towards (treatment) alternatives including an identification of side-
effects for each of the alternatives and common device related issues also from similar
benchmark devices.
Clinical data MDR art 61(1) Need to be of sufficient quality.
- A literature search for clinical data obtained with one’s own device or with equivalent
devices, based on a systematic search strategy (often PICO).
- The equivalency needs to be justified.
- Covering indications (clinical condition, physiological state).
- Clinical data appraised (quality criteria including intended purpose).
- Clinical data analyzed.

Need to be of sufficient amount, for example:

- Statistical sample size to uncover undesirable side effects.
- Cut-of date for literature search.
Safety Acceptable when free from unacceptable risk.
MDR Annex I-1
Undesirable Side effects Acceptable when weighed against the benefits see benefit - risk ratio.
MDR Annex I-8
(Clinical) Performance Acceptable when the intended performance can be achieved.
MDR Annex I-1
Benefit - risk ratio Acceptable when:
MDR Annex I-1 - Benefits outweigh the risks and undesirable side-effects.
- Benefit – risk ratio has a positive impact on health.
- Benefit – risk ratio is comparable or better than the state of the art.
- Benefits must be measurable outcomes or indirectly measurable outputs with a clinical
impact.
Clinical Investigation MDR art Perform Clinical Investigation if required.
61(4-6)
Claims Acceptable when the claim can be achieved.
MDR art 7, GSPR 23.4.c

MDR Guide for Medical Device Software 33

 Clinical Evidence Element Acceptance criteria (justify the level of clinical evidence)
Identify gaps in the GSPR This should include an identification of the residual risk originating from risk
where additional clinical data is management reports for which also additional clinical data is needed.
needed.
Identify set of instructions / • The MDSW set of instructions or algorithms which generates clinically relevant output
algorithms which need SW or benefits, need clinical evidence.
clinical evaluation • Justified based on MDR art 61(10) which set of instructions / algorithms do not need
clinical evidence
Valid clinical association Acceptable when the output associates with an indication (clinical condition or
MDCG 2020-1 physiological state).
Technical Performance Acceptable when the MDSW output is accurate and reliable for the input.
MDCG 2020-1
Clinical Performance Acceptable when the MDSW generates clinically relevant output or benefits when used
MDCG 2020-1 as intended.
PMCF plan MDR art 61(11) Consider gathering clinical data for the following situations:
• Clinical data gaps between MDD vs MDR requirements if any
• Equivalent device clinical data is used instead of own clinical data
• Technical data is used for clinical data where 61(10) is used

• Clinical Evidence per development stage

- The MDR and the Meddev guidance for Clinical Evaluation are very brief about what
clinical evidence to gather during which phase of the device life cycle.
- In principle 4 critical steps during the life cycle of a medical device can be identified
where clinical evidence plays an important role:
› Development phase: Gather (voluntary) clinical evidence to determine the State
of the Art as input for development. The development phase is out of scope of the
MDR, and currently there are no harmonized standards covering the development
phase under the MDR. Manufacturers are advised already to determine the State
of the Art in this phase.
› Clinical investigation phase: Create clinical evidence to fill the gaps and prepare
for market approval. Therefore, it is useful to identify gaps in the clinical evidence
where new clinical data is needed. (Note: the term clinical investigation is used
in the MDR, however in other jurisdictions this is called clinical study or clinical
trial). A clinical investigation is needed for MDR class IIb implantables and class
III devices (MDR high risk devices) according to MDR art 61(4), unless exempted
under MDR art 61(5 or 6). It is remarkable that the Notified Body only comes into
scope at the Pre-Market phase. It would be beneficial to have an earlier review
by a Notified Body, such as the review if an investigational device is safe and
sufficiently performing to begin a clinical investigation and if the investigation
aims to collect the right clinical data to support a later CE mark. It is argued that
such a review would be “advising by the Notified Body”, and therefore this review
should not take place. However, everybody is helped by an early Notified Body
review: the patient who knows the investigational device is as safe as possible and
performing. The manufacturer who has more certainty that the investigational
device will eventually be CE marked.
› Pre-Market phase: Evaluate if the level of clinical evidence is sufficient to
demonstrate conformity with the General Safety and Performance Requirements
(GSPR) and to obtain CE mark.
› Post-Market phase: Evaluate if there is new clinical evidence obtained during
use of the device which necessitates corrective action. In addition, review if the
medical device is still state of the art.

MDR Guide for Medical Device Software 34

 5.6.4 Clinical evidence requirements per life cycle phase according to the MDR
Figuur 14
Figure 9 Clinical evidence requirements per life cycle phase according to the MDR

Development Clinical Investigation

Phase Phase Pre-Market Phase Post-Market Phase

Evaluate clinical evidence Generate clinical data on Evaluate if there is a Review post-market
to determine state of the human subjects where sufficient level of clinical clinical data if corrective
art acceptance criteria for needed to generate a evidence for market action is needed and
safety, performance and sufficient level of clinical access update the clinical
risk-benefit ratio evidence evidence

• 5.6.4
Clinical ValidEvidence for MDD or AIMDD legacy devices
Clinical Association
Figuur 15
- Devices that are already legally on the market under the MDD or AIMDD (the
directives) are called legacy devices. The legacy devices form a special subgroup.
Under the MDR grandfathering is not defined. Grandfathering is a mechanism which
Indication(s) Benefits / Claims Valid clinical association:
regulates the acceptability under the MDR ofThe
a CE marked
MDSW output device under the directives.
should associate
Therefore, devices that are safe and performing asindication
with an intended under
(clinical the MDD or AIMDD
condition
lose their CE-mark after their MDD or AIMDD certificate
Output expires.
or physiological state).
- For that reason, the clinical evidence required for market access under the MDR for
legacy devices should preferably be created when the device still has a valid certificate
under the MDD or AIMDD as referenced by MDR art 120 (2) and (3). This newly
created clinical evidence should also be endorsed by a Notified Body with a valid MDR
certificate. In practice there is ample time to do this since there is a severe limitation
of MDR Notified Body capacity. A solution is not in sight for this unless MDR art 120 is
amended.
- When MDR Notified Body capacity is not available for a manufacturer, it is likely
that any amendment to the MDR if ever created, requires that a manufacturer has
a complete technical documentation, a valid clinical evaluation and has performed
documented
MDR Guide effort
for Medical Device to obtain in time a MDR Notified Body.
Software 7
- What is expected from a manufacturer of legacy devices?
› Conduct a gap analysis to determine if there is a lack of technical data to meet the
MDR GSPR requirements.
› Conduct a gap analysis to determine if the existing clinical data provides sufficient
clinical evidence with respect to the MDR requirements. Please note that the
definition of clinical data has changed from the directives towards the MDR, so
existing clinical evidence might no longer be valid or sufficient. Also note that
MDR art 61 (4) requires clinical investigations for MDR high risk devices, unless
exempted by MDR art 61 (4, 5, 6). When exempted the notified body shall check
if the PMCF plan is appropriate and includes post market investigations to
demonstrate the safety and performance of the device.
- If clinical data gaps have been identified, there are several possibilities to bridge those
gaps, such as:
› A (PMCF) clinical investigation.
› A PMCF investigation based on a scientifically sound questionnaires or registries.
› Narrow the intended purpose of the device to those indications only for which
sufficient clinical data is available.
- A PMS plan to gather other clinical experience data is always required.

• Clinical Evidence for MDSW

- Valid Clinical Association:
› There has to be a valid clinical association between the output of the software and
the clinical condition, disease, injury, or disability. Therefore, the manufacturer
must carry out a comprehensive literature study by searching the relevant
databases (e. g. PubMed) for systematic and non-systematic reviews as well as
meta-analyses. Moreover, he can use guidelines of medical societies as a source.
Here the key questions are:
- Does the output of the medical software correspond to the current state of

MDR Guide for Medical Device Software 35

 Phase Phase Pre-Market Phase Post-Market Phase

Evaluate clinical evidence Generate clinical data on Evaluate if there is a Review post-market
to determine state of the human subjects where sufficient level of clinical clinical data if corrective
art acceptance criteria for needed to generate a evidence for market action is needed and
safety, performance and sufficient level of clinical access update the clinical
risk-benefit ratio evidence evidence
science and technology regarding its intended purpose?
- Is the functionality of the software of clinical relevance in medical practice?
› All results of the valid clinical association examination belong to the section “state-
of-the-art in science and technology as well as clinical background” of the clinical
evaluation report.

5.6.4 Valid Clinical Association

Figuur 15
Figure 10 Valid Clinical Association

Indication(s) Benefits / Claims Valid clinical association:

The MDSW output should associate
with an indication (clinical condition
Output or physiological state).

- Technical Performance
› The manufacturer has to validate his device analytically or technically by carrying
out validation and verification tests as well as comparative tests in the case
of device equivalence. In addition, the device must comply with the relevant
standards. Finally, the manufacturer has to demonstrate the risk-based approach
in the clinical evaluation by addressing software risks, e. g. caused by incorrect
data input, insufficient precision of output, inadequate upper/lower limits,
MDR Guidetechnical failure
for Medical Device Softwareof e.g. mobile devices or the software environment, missing 7

operability, and compatibility. Here the key questions are:

- Is the software algorithm working correctly and reliably?
- Are all specifications fulfilled regarding the intended purpose?
› Standard IEC 82304-1 should be harmonized under the EU MDR in the future
and can be used for validation of stand-alone software. The results belong to
the section “route of clinical evaluation/device under evaluation” of the clinical
evaluation report.

Figuur 16
5.6.4 11 Technical
Figure Technical Performance
Performance

Technical Performance:
The MDSW output should be
Input Set of instructions Output accurate and reliable

- Clinical Performance
› The manufacturer has to measure the ability of the software to yield a clinically
meaningful output. Clinical investigations conducted with the own medical device
or an equivalent one, validation and verification, post-market surveillance and
Figuur 15
5.6.4
usability studies are possible. Here, the key questions are:
Clinical Performance
- Does the desired (precise and reliable) output of the medical software meets the
intended purpose in the target population?
- Does the
Indication(s)
output have the desired clinical significance
Intended purpose Benefits / Claims
for the corresponding
Clinical Performance:
patient population? The MDSW should generate
- Is the result of the algorithm relevant to the clinically
Output diagnosis,relevant output or
treatment or prevention
benefits when used as intended.
of a disease in a patient?
› All results of the clinical validation belong to the section “route of clinical
evaluation/device under evaluation” of the clinical evaluation report. Consider that
Figuur 16 the corresponding IMDRF guidance introduces a risk categorization for stand-
5.16.4 Clinical Evidence for MDSW example
alone software. These categories are different from the medical device risk classes
of the EU MDR and the software safety classification of standard EN 62304.
Valid Clinical Association
However, the EU MDR and the harmonized standards are relevant for placing
medical devices on the market in the EU.
Indication Input Algorithm Output Treatment Benefit

Cancer by Koson Rattanaphan

Radiation by Prime Icons DICOM
Computer by andriwidodo
TG43
from the Noun Project

MDRProstate
Guide for Medical Device Software Treatment TG43 Controled 36
Cancer CT image planning dose plan Delivery cancer
 Figuur
Figuur1516
5.6.4
Figure Clinical
5.6.412 Clinical Performance
Performance
Technical Performance

Clinical Performance:
Technical Performance:
Indication(s) Intended purpose Benefits / Claims
TheMDSW
The MDSWoutput
shouldshould
generate
be
Input Set of instructions Output clinically
accuraterelevant output or
and reliable
Output benefits when used as intended.

Figuur 16 - Clinical Evidence for MDSW example:

›
5.16.4 How to perform
Clinical Evidence for the
MDSWMDSW
example Clinical Evaluation is not easy in practice. Good

examples can be found in IMDRF SaMD WG (PD1)/N41R3 Software as a Medical

Valid Clinical Association
Figuur 15 Device (SaMD): Clinical Evaluation (Proposed Document). In the back of this
5.6.4 Clinical Performance
document there are several examples. These examples never made it in the final
guidance document
Indication Input but areAlgorithm
very useful. Output Treatment Benefit

› Radiation Treatment Planning Software is intended for use

Clinical by a trained physician
Performance:
Cancer by Koson Rattanaphan
Indication(s) Intended purpose Benefits / Claims
Radiation by Prime Icons
Computer by andriwidodo in radiation therapy to create a radiation treatment
DICOM

TG43
The MDSWplanshould
for the treatment of
generate
from the Noun Project
tumors after approval by thatOutput clinically relevant
physician. The radiation treatment plan output or is used to
benefits when used as intended.
drive a radiation treatment Treatment
Prostate
device, which executes TG43
the plan to radiate the tumor.Controled
› Below is an CT
Cancer example
image from Radiation
planning Therapy.dose plan Delivery cancer

Figuur 16
Figure 13 Clinical
5.16.4 ClinicalEvidence
Evidence for MDSW example
Technical
for MDSW Performance:
example Used according intended purpose:
• Accuracy of algorithm(s) • Safety (including no unacceptable
• Reliability: risk or undesirable side-effects)
• Interoperability
Valid Clinical Association • Clinical Performance
• Usability • (Claimed) Benefits
• Cybersecurity • Positive Risk / Benefit ratio versus
• Data privacy security alternative treatment options
Indication Input Algorithm Output Treatment Benefit
(State of the Art)

Cancer by Koson Rattanaphan

Radiation by Prime Icons DICOM
Computer by andriwidodo
TG43
from the Noun Project

Prostate Treatment TG43 Controled

Cancer CT image planning dose plan Delivery cancer

Technical Performance: Used according intended purpose:

• Accuracy of algorithm(s) • Safety (including no unacceptable
• Reliability: risk or undesirable side-effects)
• Interoperability • Clinical Performance
• Usability • (Claimed) Benefits
• Cybersecurity • Positive Risk / Benefit ratio versus
• Data privacy security alternative treatment options
(State of the Art)

MDR Guide for Medical Device Software 8

MDR Guide for Medical Device Software 8

MDR Guide for Medical Device Software 37

Figuur 19
5.6.5. Clinical Evaluation
5.6.5 - Clinical Evaluation
The following table gives the Clinical Evaluation Stages and its contents.

Stage 0: Stage 1: Identification of Stage 1: Identification

Stage 3: Analysis of the Stage 3: Analysis of the
Definition of the scope of pertinent data held by of pertinent data from
clinical data (A7) clinical data (Meddev A7)
the clinical evaluation the manufacturer (8.1) literature (8.2)

Device Description and Premarket data Demonstration of Compliance to specific Supporting labelling &
scope (7 & A3): • Risk Management
Equivalence (A1; MDCG GSPR requirements promotional material (6.1):
2020-5 ): (MDCG 2020-6):
• Names & Codes • Bench testing • Intended use (6.1)
• Legal Manufacturer • Usability Study (6.1) • Based on Clinical, Safety (10 & A7.41 & MDR • Claims (6.1; MDR art 7)
• Regulatory status / • Animal Testing Technical, Biological GSPR 1) • Indications (6.1)
Classification • Pre-Market Clinical aspects. • Acceptability of side- • Contra-Indications (6.1)
• Intended purpose, Investigations • Access to Technical File effects (10 & A7.4 & • Precautions & warnings
(Contra)Indications & • Equivalent device(s) MDR GSPR 8)
Claims Post market data conform to MDD / • Performance (10 & A7.3 Stage 4: Clinical
• Detailed description • Previous clinical
MDR? & MDR GSPR 1) Evaluation Justifications
• Technical File evaluations
• Justify issues. • Acceptable benefit/ and Conclusions
references • Post Market Clinical
risk profile (10 & A7.2 &
• Overview of changes Literature Search MDR GSPR 1):
Follow-up (&IIR)
(A4 & 5): - Benefits: • Conclusion Clinical
• Post Market
Clinical background, - Improved clinical Evaluation Report (11)
Surveillance • Identification (search)
current knowledge, state outcome • Clinical Investigation
• New risk from PMS / - PICO
of the art (8-10 & A4 & - Improved Quality justification (10.2c, 10.3
PMCF - Own / equivalent
5; MDCG 2020-6): of Life & A2)
• New claims device
- Improved diagnosis • PMCF Justification
• Literature search: • Design changes - Risks (unacceptable)
- Improved public (10.2d, 10.3 & Meddev
- Acceptable Risk • Review State of the Art - Claims
health impact 2.12)
/ Benefit ratio vs • Update literature • Screening duplicates
- Risks: • Clinical Development
clinical alternatives search and analyses • Screening relevance
- Residual risks Plan (MDR A14-A1a)
- Acceptable
- Side-effects • Update frequency
undesirable side-
Clinical Evaluation (6.2.3)
effects vs clinical
Stage 2: Appraisal of GSPR requirements for
alternatives
pertinent data (A6) software / diagnostics
• Compliance Common Evaluators
(MDCG 2020-1 ):
Spec./ (Harmonized)
•
Standards - On full text article • Valid clinical C.V.
• Risk mitigation of risks - On degree of quality, association Check qualifications (6.4)
from vigilance reports, relevance and • Technical performance Declaration of interests
MAUDE, etc contribution • Clinical performance (A11)

• State of the Art

- Demonstration of the State of the Art has several interpretations:
› Demonstration of State of the Art based on a literature review as outlined in
Meddev 2.71 rev 4 art 8.2 and Meddev 2.71 rev 4 annex 5.1:
- Demonstration of an acceptable benefit - risk ratio when taking into
Figuur consideration the medical alternatives (MDR recital (49)).
5.6.5 State of the Art
- Demonstration of acceptable undesirable side effects when taking into
consideration the medical alternatives. Medical alternatives can be alternative
therapeutic interventions, benchmark devices, measures for the management of
diseases, or others.
- Demonstration of State of the Art based on existing medical guidelines from, for
example, professional societies.
› Demonstration of State of the Art State of the art
(Meddev 2.71 rev 4 annex 7.1) through the
application of (harmonized) standards or common specifications. Under the MDR a
justification is needed about that the use of these standards is justified. The most
up to date list of standards can be found at the FDA website called the recognized
standards.

2D TG43 TG186 Monte Carlo

MDR Guide for Medical Device Software 38

MDR Guide for Medical Device Software 9
 Spec./ (Harmonized)
•
Standards - On full text article • Valid clinical C.V.
• Risk mitigation of risks - On degree of quality, association Check qualifications (6.4)
from vigilance reports, relevance and • Technical performance Declaration of interests
MAUDE, etc contribution • Clinical performance (A11)

Figure
Figuur
14 State of the Art
5.6.5 State of the Art

State of the art

2D TG43 TG186 Monte Carlo

• Benchmark / similar devices

- A similar device is a device for which the intended use, the biological, technical and
MDR Guide for Medical Device Software 9

clinical characteristics are similar (comparable) to your own device. A benchmark

device is a similar device to which the safety and performance of your own device can
be compared.
- In cases where equivalence cannot be demonstrated under the MDR, the clinical data
of benchmark / similar devices may be useful for a variety of other purposes, such as:
› Ensuring that risk management is comprehensive by identifying relevant hazards
and clinical risk.
› Understanding the state of the art, the natural course of a disease and alternative
available treatment options.
- Helping to define the scope of the clinical evaluation, by identifying any design
features in similar devices that pose special safety or performance concerns.
- Helping to create clinical investigation plans or post-market clinical follow-up
(PMCF) plans, and PMS plans.

• Equivalent devices (see MDR Annex XIV (3)

- An equivalent device is a device for which the biological, technical or clinical
characteristics match your own device as required by the MDR Annex XIV (3).
- The manufacturer can demonstrate equivalence to already marketed medical devices.
Annex XIV (3) of EU MDR specifies 3 characteristics, that manufacturers must
consider when demonstrating equivalence:
› Technical (e.g. conditions of use, properties, and algorithms).
› Biological (not applicable for software).
› Clinical (e.g. clinical condition or purpose, population and performance).
- If equivalence can be demonstrated according MDR annex XIV section 3, then clinical
data of the equivalent device can be used for the device under evaluation to support
the conformity assessment. The clinical data of an equivalent device may be used to
generate clinical evidence for acquiring market approval.
- The equivalency assessment must be based on the relevant aspects of technical,
biological and clinical characteristics of both devices. A gap analysis should be
conducted by the manufacturer to assess any clinically significant difference between
the device under evaluation and the device to which equivalence is claimed. The
demonstration of equivalence can be based on multiple devices, although this is often
challenged by regulators or Notified Bodies. The use of multiple equivalent devices
is particular important for software, where often the features of multiple devices are
combined.
- For class I devices and class IIa and IIb devices considerations of equivalency shall
be based on proper scientific justification. The manufacturer must have sufficient
levels of access to the data relating to the equivalent devices, such as brochures
with technical characteristics, an instruction for use, measurements of performance
characteristics, etc.
- For MDR class III devices in practice equivalency can only be accomplished for an
own equivalent device, since it is very difficult to meet the additional requirement
from MDR art 61-5, which says that the manufacturer of the device under evaluation
should have a contract in place with the manufacturer of the equivalent device which
should explicitly allow full access to the technical documentation on an ongoing basis.
- To demonstrate equivalence, the characteristics of the compared devices must match.
It is therefore important that the demonstration is based on adequate scientific

MDR Guide for Medical Device Software 39

 justification. Additionally, the manufacturer must clearly show that he has sufficient
access to the comparator data.
› It is not reasonable to demand that equivalence is demonstrated for the software
code.
› The principles outlined in ISO 10993 series of standards for the biological
evaluation of medical devices can be adopted.
› Manufacturers may identify more than one equivalent device to the device under
evaluation, but each device shall be equivalent to the device under evaluation in all
the listed technical, biological and clinical characteristics. Note: all is a problem for
software.
› Pre-clinical data for the consideration of equivalence can be used.

• Qualified assessment
- The clinical evaluation report must receive a qualified assessment from the
manufacturer and from the Notified Body for MDR class IIa/b devices (MDR medium
risk devices) and MDR high risk devices. This assessment includes an evaluation if
there is a sufficient level of clinical evidence to claim that the device has a beneficial
benefit - risk ratio and can be considered State of the Art.

5.6.6. Clinical Development Plan

A Clinical Development Plan (also called strategy) is required for every Medical Device. An
example is shown for a hardware product, so that it is clear what is expected from such
a plan. MDSW often does not deliver directly patients benefits / outcomes or endpoints,
therefore for each MDSW it should be seen how to create the Clinical Development Plan.

Typical MDSW activities which fit in such a plan are:

• Valid Clinical Association study. Objective: Proof of concepts. Endpoint: a valid clinical
association.
• Usability study. Objective: Safe and easy to use. Potential endpoint: usability.

Table 12 Clinical Development Plan

Milestones Study design (examples) Potential acceptance criteria

Development • Formative and summative usability study • Objective: Safety, easy to use, easy to learn
stage per ISO 63266 Potential endpoints: Usability
Pilot stage • Structured case report(s) / first in man Objective: Proof of concept
Potential endpoint(s): Correctly treat subjects, meet
intended purpose
• Prospective uninterrupted case series. Objective: Safety & Performance
Potential Endpoint(s): Toxicity; tumor response; local control
Pivotal stage • Prospective study with matched Objective: Effectiveness compared to standard treatment
(historical) controls. Potential Endpoint(s): (disease-free) survival;
• Randomized clinical trial. local control; acute toxicity
• Registry based trial.
Postmarket PMCF based on real world data: Objectives see Annex XIV part B 6.1:
stage • Retrospective registries • confirming the safety and performance of the device throughout
its expected lifetime
• identifying previously unknown side-effects and monitoring the
identified side-effects and contraindications
• identifying and analyzing emergent risks on the basis of factual
evidence
• ensuring the continued acceptability of the benefit-risk ratio
• identifying possible systematic misuse or off-label use of the
device
Endpoint(s): Long-term toxicity, (disease-free) survival, Rare
side effects, Patient-Reported Outcomes
PMCF based on real world data: Objectives see Annex XIV part B 6.1.
• Physician questionnaire Endpoint(s): Usability
• Patient questionnaire Endpoint(s): Quality of Life

MDR Guide for Medical Device Software 40

 5.6.7. Clinical Investigation

Clinical Investigations are often called clinical trials or clinical studies. The manufacturer
must consider a clinical Investigation if he:
• Launches completely new software with new features and functionality.
• Modifies existing software in such a way that clinical safety and performance may be
affected.
• Uses existing software for a new medical purpose.

In general, manufacturers must conduct a Clinical Investigation when it comes to high

risk medical devices like class III and implantable devices (MDR art 61 (4)). Furthermore,
the manufacturer may consult an expert panel (Art. 106) in case of class III and class IIb
active devices intended to administer or remove a medicinal product (Art. 61 (2)). The
expert panels give advice in product development and assist the EU Commission in the
preparation of guidelines and common specifications. There is one exception concerning
the high-risk devices mentioned above. If the clinical evaluation of a medical device
marketed under the EU MDD is based on “sufficient clinical data”, no clinical study is
required (Art. 61 para. 6). However, there is currently no general definition of “sufficient
clinical data”, as their kind and extent are highly dependent on the type of medical device.
In the future there will probably be EU-wide evaluation criteria. Respective guidelines or
common specifications should be device specific.

The patient data collected is also regulated by the GDPR, and the patient should give a
specific consent for this, which by default does not cover secondary use of the patient
data. Therefore, also future use of the patient data should be considered, so that the
patient consent also includes this.

The figure below shows the notification and review requirements for pre and post market
clinical investigations. A PMCF study is a Retrospective Investigation.

Figuur 22
Figure 15Clinical
5.6.7 – Clinical investigation registration requirements
Investigation

74.1 PMCF-I CE marked product:

62-1 Clinical investigation
(with CE; including class • Registries
for conformity assessment 82.1 Other CI (= IIS, …)
III conformity assessment • Validation using
PMCF registries) curated clinical data

Outside intended use,

Yes and used for CE marking?

No

Interventional and / or
burdensome? No
Yes

• 62-4a / 70-1 CI • 62-4a / 74 CI • 62-4b EC Review • No clinical

Application to MS Notification to (one) MS (see national law) investigation
• 62-4b EC Review • 62-4b EC Review
(see national law) (see national law)

Figuur 23
5.8.1 Cybersecurity

• MDS2
• Security documentation
• Security guidelines
• Security support

Product supplier System integrator Asset owner

(Manufacturer) (Hospital IT or External IT (Hospital operator)
service provider)
Role: Role: Role:
• Develops
MDR and
Guide for supports
Medical Device Software• Designs, deploys and maintains • Develops and supports 41

Responsibility: Responsibility: Responsibility:

• Secure Software Development • Secure setup • Asset management
5.7. Usability

• MDR art 83 (3f) Identification of PMS data to improve usability

• MDR Annex I (5) Reduce risks use error
• MDR Annex I (14.2) Reduce risk design
• MDR Annex I (14.6) Ergonomic principles
• MDR Annex I (23) (23): Information supplied with the product.
• IEC 62366-1 Application of usability engineering to medical devices
• IEC 62366-2 Section 15.3 Design software user interfaces
• ISO 9241 series ergonomics of human-computer interaction
• ANSI/AAMI HE75 section 21 Software-user interfaces
• BSI The growing role of human factors and usability engineering for medical devices

IEC 62366-1 is usability for software and IEC 60601-1-6 is for MDSW integrated in
electronic equipment and can be used in addition to IEC 62366-1 if applicable. IEC 62366-
1 has to be used together with ISO 14971 risk management. IEC 62366-1 describes the
usability engineering process aimed at ensuring an acceptable risk for a MDSW. IEC TR
62366-2 explains in more detail how usability engineering can be designed, and can be
next to IEC 62366-1.

The MDR has to following sections that are applicable for usability:
• MDR art 83 (3f): When the MDSW has been placed on the market the manufacturer has
to record incidents and report them as part of Post Market Surveillance and consider
the need to improve the usability of the MDSW.
• MDR, Annex I (1) MDSW has to be suitable for their intended purpose and the
environment in which the device is used. IEC 62366-1 calls this the use specification.
• MDR Annex I (3): MDSW has to prevent foreseeable misuse. The following is expected:
- Analyze foreseeable misuse of similar devices from literature, vigilance databases and
post market surveillance data.
- Define use scenarios with subsequent task analysis
- Monitoring of users during formative and summative evaluations
• MDR Annex I (5): MDSW has to be designed to eliminate or reduce risks related to use
error:
- Reduce risks related to the ergonomic features of the MDSW and the use environment
(design for patient safety).
- Consider technical knowledge, experience, and health condition of the user (design
for type of user).
- The following is expected:
› Inherent safety: a switch that does not exist cannot be pressed by accident.
› Protective measure: a switch that has a flip cannot be pressed by accident.
› Information for safety: for instance, a warning in the manual for pressing a switch
by mistake.
• MDR Annex I (14.1): MDSW has to be designed to eliminate or reduce risks from use in
combination with other devices including interoperability. These combinations have to
be included in usability requirements and inherent safety against faulty connections has
to be implemented as far as possible.
• MDR Annex I (14.2): MDSW has to be designed to remove or reduce as far as possible
the risk of injury, by implementing ergonomic features.
• MDR Annex I (14.6): Any measurement, monitoring or display scale shall be designed
and manufactured in line with ergonomic principles, taking account of the intended
purpose, users, and the environmental conditions in which the devices are intended to
be used.
• MDR Annex I (21.3): Displays have to be understandable.
• MDR Annex I (22): The MDSW has to be safe for use by lay persons.
• MDR Annex I (23): The instructions for use and labels for the DSW have to be usable.

The usability engineering process has the following elements:

• Usability engineering plan

MDR Guide for Medical Device Software 42

 -T  he usability engineering plan shall describe the project and provisions for
implementing the usability engineering process.
• Usability input data
- The project starts with gathering the design input data for usability, such as:
› MDR and other Regulatory requirements, like for the instruction for use or the
labelling.
› User requirements form product managers, application specialists, service, sales,
etc.
› Data from previous projects.
› Feedback from users on previous versions of medical devices.
› Analysis of similar medical devices.
• Use specification
- The use specification contains information about:
› Intended purpose.
› Indications and patient groups.
› User profiles.
› Use environment.
› Operating principles.
• Identifying characteristics for safety
- The usability analysis process is performed in parallel to the ISO 14971 risk
management process. This step identifies:
› The primary operating functions in the device.
› The use scenarios.
› The possible use errors.
• Identifying hazardous situations
- This step identifies:
› The use specification.
› Data from comparable devices or previous generations of the device.
› User errors identified in the previous step.
• Identifying hazard-related use scenarios
- This step identifies sequence of events and the related hazards.
• Selecting hazards-related scenarios for summative evaluation
- This step identifies hazard-related scenarios for the summative evaluation based on
objective criteria. Usually the scenarios that have most impact on the benefit risk
ratio.
• Identifying mitigations and user interface specification
- The risks related to the use scenarios are evaluated on severity, frequency, and
possibly detectability. Mitigation actions are identified. The mitigation actions are
documented in the user interface specification (see ISO 14971 (6.2):
› Changes in user-interface design, including warnings like message boxes.
› Training of users.
› Information in the instructions for use and labelling.
• Formative Evaluation
- The formative evaluation is performed during the design phase. The formative
evaluation can be started with internal employees and is usually also performed
in later stages with users. The methods of evaluation depend on the context:
questionnaires, interviews, presentations of mock-ups, observation of use of
prototypes.
• Summative evaluation
- The summative evaluation is performed at the end of the design phase. It can be
done after the verification, or during the validation of the MDSW. The summative
evaluation has to be done with users. FDA guidance provides samples sizes for each
user group. The evaluation has to be done in a (simulated) use environment.

MDR Guide for Medical Device Software 43

5.8. Cyber security
5.8.1. Introduction

General:
• MDR Annex I (14.2.(d)) MDSW and IT networks interaction risks
• MDR Annex I (17.2) State of the Art, Software Development Life Cycle, Risk
Management, (Cyber)security and Verification and Validation
• MDR Annex I (17.3) Mobile platforms
• MDR Annex I (17.4) Hardware, IT networks, (Cyber)security
• MDR Annex I (18.8) Unauthorized access
• MDCG 2019-16 Medical Devices: Cybersecurity
• IMDRF/CYBER WG/N60 Principles and Practices for Medical Device Cybersecurity
• ENISA NIS directive All devices: Network and Information Security
• RED directive (Cybersecurity part under construction)
• GDPR (General Data Protection Regulation)

Requirements:
• BSI-CS 132 Network-Connected Medical Devices: Cyber Security Requirements
• ISO/IEC 15408 IT products and systems: security techniques
• IEC 62443 industrial automation and control systems: processes, functional
requirements, security

Security risk management:

• AAMI TIR 57 Security risk management for medical devices
• IEC 60601-1: Appendix H.7 Medical electrical equipment: Causes of hazardous
situations of medical de-vices in IT networks.

Verification and validation testing:

• UL 2900-1 Network-connectable products: verification and validation testing
• UL 2900-2-1 Network-connected components of healthcare systems: verification and
validation testing

Manufacturer Disclosure Statement and implementation:

• HIMSS/NEMA HN1-2013 (MDS2) MDSW and IT networks: Manufacturer Disclosure
Statement on Medical Device Security Note: The MDS2 statement is related to the
requirements in EN 80001-1 section 3.5.
• IEC 80001 Healthcare IT networks: risk management, IT networks
• IEC 80001-1 Healthcare IT networks
• IEC/TR 80001-2-2-2 Healthcare IT networks
• ISO 27799 Healthcare IT networks: information security, management

Hackers have found medical devices and hospitals vulnerable for cyber-attacks, such as
the crippling of hospitals with the “WannaCry” ransomware. Although medical devices
are often not the primary target of ransomware, medical devices in a network are often
indirectly affected. DoS and DDos attacks disrupt services of a health IT network and,
make devices or network resources unavailable to its user.

Therefore, the MDR requires manufacturers to establish, implement, document, and

maintain a risk management system, including for security and cybersecurity risks. This
system must be a continuous iterative process throughout the lifecycle of a device. The
regulation requires manufacturers to control the risks related to the IT environment
and single fault conditions. The manufacturers have to mitigate the impact of security
vulnerabilities in the host platform, in the operating system or in the network and to
ensure their devices are resilient against attacks and manipulation. Build-in cyber
security is now a must, however which regulations, and standards to meet is not clear,
since this area is quickly evolving.

MDR Guide for Medical Device Software 44

 Outside intended use,
Yes and used for CE marking?

No

Interventional and / or
burdensome? No
Cyber security is also very complex, since Yes several stakeholders need to cooperate with
each other. The hospital asset owner is responsible for secure operation of the Medical
• 62-4a / 70-1 CI • 62-4a / 74 CI • 62-4b EC Review • No clinical
Device. The hospital
Application to MS system integrator
Notification to (one)isMS
responsible for implementing
(see national law) a secure IT
investigation
environment.
• 62-4b EC Review The Medical Device
• 62-4b manufacturer is responsible for developing a secure
EC Review
(see national law) (see national law)
solution, including security requirements for the asset owner and system integrator to
protect the Medical Device.

Figuur 23
5.8.116
Figure Cybersecurity
Overview of cybersecurity roles

• MDS2
• Security documentation
• Security guidelines
• Security support

Product supplier System integrator Asset owner

(Manufacturer) (Hospital IT or External IT (Hospital operator)
service provider)
Role: Role: Role:
• Develops and supports • Designs, deploys and maintains • Develops and supports

Responsibility: Responsibility: Responsibility:

• Secure Software Development • Secure setup • Asset management
Life Cycle • Network configuration • Policies
• Security capabilities • Securely configured • Secure operation
• Security testing • Integration best practices • Continuous monitoring
• Product security • Security commissioning • Applying patches and
requirements • Asset hand over updates
• Product support • Maintain a secure solution • Active engagement
• Patches and updates • Requirements

• Requirements

The MDR requires the implementation of cyber security in their products and also define
requirements for the IT environment, so that the devices can operate securely. These
requirements are defined in Annex I in paragraph 14.2d, 17.1, 2 and 4. The expectation is
that Medical Devices are secure by design and address by default cyber security threats.

The UL standards UL 2900-1 and UL 2900-2-1 describe verification and validation of

security risk control measures against design requirements for vulnerabilities, exploits
and software weaknesses. IEC 60601-1 Appendix H.7 describes possible causes of
hazardous situations of medical devices in IT networks.
MDR Guide for Medical Device Software 10
The usage of mobile devices is described in the DTS (Diabetes Technology Society)
“Guidance for Use of Mobile Devices in Diabetes Control Contexts” and wireless diabetes
devices are described in the DTSec standard.

The IEC 80001-1 and related standards are for asset owners of Healthcare IT Networks.
Another family of standards covering this is the ISO/IEC 27000 series. The IEC
62443 Standard Series are helpful for defining cyber security requirements for critical
infrastructures and are also very applicable for system integrators.

5.8.2. Cyber security risk management

In addition to risk management according to ISO 14971, risk management for cyber
security has to be performed. The security of a device can negatively impact the safety of
the device. For instance, when the operation of ventilators on an IC unit have a password
protection (secure). In an emergency situation, this can be unsafe when the operator does
not have the password. So, when doing risk management for security, always the trade-
off for the safety and performance of the device needs to be assessed.

MDR Guide for Medical Device Software 45

For the security risk management AAMI TIR 57 can be used, which complements the
safety risk management activities of ISO 14971. Alternatively, the risk management
method of ISO/IEC 15408 standards can be used.

5.8.3. Secure Development Life Cycle (SDLC)

The process to design and develop, maintain and decommission medical devices while
considering their associated cybersecurity risks is the best way to build security into
devices. A secure SDLC involves integrating security testing and other activities into an
existing development process, such as writing security requirements alongside functional
requirements and performing an architecture risk analysis during the design phase of the
SDLC.

5.8.4. (Self)-certification

Owners of Healthcare IT networks regular request Medical Device Manufacturers that

they comply with cyber security requirements, mostly with a MDS2 statement. The MDS2
is defined in HIMSS/NEMA HN1-2013 “Manufacturer Disclosure Statement on Medical
Device Security”. This statement is based on the implementation of the requirement in IEC
80001-1 Section 3.5 and the requirements in IEC/TR 80001-2-2-2.
The EC has adopted the NIS Network and Information Security directive and is also
working on integrating Cyber security in the RED directive. The NIS directive requires
health care providers to take cyber security measures. Which can include Medical Device
manufacturer audits and certifications. In addition the EC is working on certification
requirements through ENISA (European Union Agency for Cybersecurity).

5.9. GDPR (Privacy)

If the MDSW handles patient data, then the General Data Protection Regulation (GDPR.
In the Netherlands called Algemene verordening gegevensbescherming (AVG)) applies
to the processing of personal data. Exceptions apply e.g. to certain authorities and
private persons. An important part of the GDPR principles concerns the territorial scope.
Accordingly, the GDPR applies to companies which have customers in the EU, track
customers by means of data profiling or offer goods or services in the EU in general. The
fact whether such a company has its own branch in the EU is not relevant. The GDPR
is valid in every case. A further aspect of GDPR principles affects the way how data are
processed in general. These principles are:
• Transparency.
• Purpose limitation.
• Data minimization.
• Accuracy.
• Storage limitation.
• Integrity.
• Confidentiality.

5.9.1. Personal Data

GDPR only applies for personal data. Personal data means any information relating to
an identified or identifiable natural person which is called a “data subject”. Processing of
personal data is generally prohibited and is only allowed if a legitimation exists (in the
GDPR). However, there are special categories of personal data whose processing has to
meet stricter requirements. This applies for data revealing racial or ethnic origin, political
opinions, religious or philosophical beliefs, or trade union membership. Also, genetic
data, biometric data, data concerning health or data concerning sexual orientation are
considered to be special categories. When we talk about medical devices and medical
software, of course “data concerning health” is of particular interest. Unfortunately, as

MDR Guide for Medical Device Software 46

shown above, the GDPR apparently prohibits their processing. However, there are some
exceptions whose precise understanding is important for a manufacturer or operator of
medical software.

There are four relevant situations in which manufacturers or operators of medical devices
(or software) can lawfully process health:
• The data subject has explicitly given consent.
• The processing is necessary for the purpose of medical treatment.
• For reasons of public interest in the area of public health.
• For assuring high quality standards of the product.

However, the GDPR restricts the processing of health data as part of the medical treatment
because only specialized personnel are permitted to do that. In addition, the GDPR explicitly
allows the EU member states to introduce additional regulations at this point.

5.9.2. Roles and Responsibilities

The GDPR principles include certain roles with the processing of personal data, the
controller, the joint controller, the processor, or the third party. The controller is the
responsible body and determines the purposes and means of the processing of personal
data. Two or more controllers are joint controllers when they determine the purposes and
means of data processing together.

The processor is an external party and processes the controller’s data on behalf of him. A
processor is thus a kind of an external “employee” of the controller which has to process
the data to the requirements of the controller. Hence, it is very important to evaluate who
plays which role in order to find out what obligations each party has in each individual
case. If you are a processor, you are responsible for meeting the legal requirements of the
GDPR.

The manufacturer then takes the necessary technical and organizational measures as
part of the risk management. It is often difficult for medical device manufacturers to
judge whether they are actually “responsible” for the data processing of their product.
Not only the contractual aspects but also the technical and organizational conditions
are important. The medical device design and the way how it transfers and processes
data also play an important role. If, for example, a manufacturer gets access to patient
data for remote maintenance, he is a processor. In this case the controller has to make
an agreement with the processor. If the processor processes the data independently (for
other purposes on his own behalf), he becomes the controller.

5.9.3. Access, Rectification and Erasure

The data subject therefore has the right to obtain confirmation from the controller as
to whether the controller has processed data relating to him or her. In this case, he or
she has the right to access these personal data, i.e. also to a copy of all data stored by
the controller. In addition, the data subject may also request information on a range of
supplementary information, such as the purpose of the processing, the duration of the
storage or any recipients of the data. Moreover, the data subject has the right to request
that the controller rectify inaccurate personal data without delay. The same applies to
the deletion of personal data, e.g. if the data subject withdraws its consent, if data has
been unlawfully processed or if the data is no longer required for the respective purpose.
It follows that the more networked medical technology is and the more players are
involved in the application of medical software, the more costly it should be to implement
the above-mentioned legal requirements consistently. However, it becomes even more
complex if personal data is published in any way in the use of a medical product or
medical software. In this case, the controller has to take reasonable steps, including
technical measures, to cause deletion of the respective data. This also includes search
engines or public directories. Fortunately, this case shouldn’t be the rule.

MDR Guide for Medical Device Software 47

5.9.4. Profiling

Another issue of the GDPR principles regarding the rights of the individual are his/her
rights in the case of profiling. Profiling is any form of automated processing of personal
data in order to evaluate personal aspects relating to a natural person, including health.
Therefore, profiling is a relevant component of many medical devices including medical
software. Examples are a patient monitoring system or a device to continuously measure
a metabolic component. It is therefore important to know that the data subject has the
right not to be subject to a decision concerning him or her or similarly significantly affects
him or her. However, there are restrictions to this rule, especially if the data subject has
explicitly consented or if a contract has to be fulfilled. Nevertheless, the GDPR principles
mentioned above, transparency, access, rectification, and erasure apply as well in the
case of profiling. For example, the data subject has the right to know whether and how
profiling is carried out. The controller has to provide meaningful information about the
logic involved as well as the scope and desired effects of such processing. The data
subject has the possibility to revoke his consent at any time.

5.9.5. Data Portability

What happens to my data when I change a provider? Also, here the GDPR strengthens
the rights of the data subjects. For the first time there is a right on data portability.
Accordingly, the data subject can receive the personal data concerning him or her, which
he or she has provided to a controller. Then, the controller has to provide the data in
a structured, commonly used and machine-readable format. The GDPR principles also
demands that the transfer of data from one controller to another controller has not to
be slowed down by any (technical) hurdles. It will become clear in the future how the
controller can technically implement this demand together with the medical devices or
software manufacturers. The more players are involved in a medical device, system or
method, the more difficult it will be to provide consistent interfaces and processes for
smooth data transfer. Here, too, privacy by design will quickly pay off.

5.9.6. Risk Management

The GDPR recognizes that data processing procedures represent high risks for the privacy
of persons. The measures for the protection of the data has to be appropriate. The GDPR
requires a special impact assessment for data processing that involves a particularly high
risk. This could be e.g. the case when profiling is performed. The controller is responsible
for this special form of risk management. In particular, he or she evaluates the cause,
type, specificity and severity of the risk and takes necessary measures from this. By
doing so, the controller has to prove that processing of personal data is in compliance
with the GDPR. If the controller cannot limit the risk by suitable technical measures, he
or she should consult the supervisory authority before processing. The data protection
assessment is therefore a kind of preliminary check.

5.9.7. Privacy by Design (GDPR)

It is part of the GDPR principles to think about data protection from the outset, to view
it holistically and to implement it in all processes. Consequently, the GDPR demands
that the controller establishes privacy by design in his organization and therefore in
his processes. This requirement applies to all data processing systems (software and
hardware) that collect and process personal data from data subjects. Therefore, it applies
equally to old systems and, of course, to new systems to be purchased. The controller
is obligated to privacy by design. Software manufacturers are not obliged to develop or
offer data protection-friendly technology for GDPR reasons unless they are controllers
themselves. However, controllers may expect to receive products with which they
can implement privacy by design in their processes. This will create a corresponding
market pressure. If a (medical) software manufacturer studies the GDPR in detail, it will

MDR Guide for Medical Device Software 48

be clear exactly what customers need in order to be “compliant”. If the manufacturer
advertises “GDPR compliant” or “compliant to the current legislation” and the software
does not meet these requirements, a civil legislation problem can arise. Therefore, the
manufacturer should inform a customer if the software design is not GDPR compliant,
e.g. due to a modular structure.

5.9.8. Privacy by Default (GDPR)

According to GDPR, a controller can only use software and hardware which has data
protection-friendly pre-settings. Hence, data protection and data security has to be
implemented routinely in devices, software and systems. Consequently, privacy by default
should also become standard in medical devices and medical software. In the standard
settings, software may only process as little personal data as possible and transmit as
little data as possible to “outsiders”. Of course, this also applies to medical software.
However, this has to function perfectly as part of medical diagnosis or therapy. Here,
both the software manufacturers and the controllers has to weigh the compromise
between medical device performance and data protection in view of the GDPR principles.
Overall, the manufacturer should transparently explain to the customer or the processor,
respectively, how the software is structured and to what extent the manufacturer can
influence privacy by design and privacy by default. As an appropriate measure the
manufacturer should create corresponding documentation that describes in detail how
the software realizes GDPR requirements.

5.10. Interoperability

MDR art 2 Definition (26) Interoperability

MDR Annex I (14.5) Interoperability
EGIZ Gedragscode Elektronische Gegevensuitwisseling in de Zorg
NEN 7510 Informatiebeveiliging voor de zorgsector
NEN 7512 Vertrouwensbasis voor gegevensuitwisseling
NEN 7513 Logging
NEN 7521 Toegang tot patiëntengegevens
ISO 13972 Zorg Informatie Bouwstenen (Health and Care Information Models (HCIM))

MDSW interoperability is quickly evolving with many institutes trying to create order. The
main institutes where standards and information can be found are:
• NICTIZ (the Dutch competence centre for electronic exchange of health and care
information).
• HIMMS (Healthcare Information and Management Systems Society).
• IHE (Integrating the Healthcare Enterprise).
• HL7 (Health Level Seven).
• SNOMED (SNOMED CT or SNOMED Clinical Terms is a systematically organized
computer processable collection of medical terms providing codes, terms, synonyms
and definitions used in clinical documentation and reporting.).
• CDISC (Clinical Data Interchange Standards Consortium).
• ISO (International Organization for Standardization).
• NEN (Stichting Koninklijk Nederlands Normalisatie Instituut).

MDSW can share health data with information systems, devices, applications, or other
entities. If this is done without any restrictions, we call this interoperability. Standards,
protocols and procedures are required for interoperability of entities. There are four levels
of Interoperability:
• Foundational (Level 1): Establishes the inter-connectivity requirements needed for one
system or application to securely communicate data to and receive data from another.
• Structural (Level 2): Defines the format, syntax and organization of data exchange

MDR Guide for Medical Device Software 49

 including at the data field level for interpretation.
• S emantic (Level 3): Provides for common underlying models and codification of the data
including the use of data elements with standardized definitions from publicly available
value sets and coding vocabularies, providing shared understanding, and meaning to
the user.
• Organizational (Level 4): Includes governance, policy, social, legal and organizational
considerations to facilitate the secure, seamless and timely communication and
use of data both within and between organiza-tions, entities and individuals. These
components enable shared consent, trust and integrated end-user processes and
workflows.

The information model (data attributes), the functional model (role played within the
interoperable system), and the architectural model (how the device is connected within
the system) should be considered during the development. Design inputs have to include
the desired functional and performance characteristics of the electronic interface.

Manufacturers of interoperable medical devices should perform a risk analysis and

conduct appropriate testing that considers the risks associated with interoperability,
the anticipated users, reasonably foreseeable misuse, and reasonably foreseeable
combinations of events that can result in a hazardous situation.

If the medical device/application is meant to exchange or use data with or from other
entities, then the device description should include a description of the information
exchanged, how it is exchanged, which (International) standards, procedures and/or
protocols are used and the impact the exchanged information has on the device or other
impacted devices. This may include some or all the following elements based upon the
claims of data exchange and use made for the medical device:
• Explain the purpose of the interface and the role the device plays within an
interoperable system. This may be as simple as stating that the device is meant to
deliver device data to a specific product, technology, or system architecture described
in a particular standard.
• Specify if the interface is meant to transmit, receive, or exchange information.
• Specify any international standards, procedures and/or protocols used, including
relevant version numbers and dates.
• Describe the requirements for timeliness and the integrity of the information (e.g.
sample rate, transmission rate).
• Describe the communication format, rate, and transmission method.
• Describe how updates, maintenance is handled in relation to the used standards.
• Discuss the limitations (what the user should not do), contraindications, precautions,
and warnings.
• Describe the functional and performance requirements.
• List the Application Programming Interface (API) if the device is software that can be
used by other software, medical device, or system.

Interoperability Standards can be divided in the following categories:

• Vocabulary/Terminology Standards
- Health information systems that communicate with each other rely on structured
vocabularies, terminologies, code sets and classification systems to represent health
concepts.
- RadLex (example): A unified language of radiology terms for standardized indexing
and retrieval of radiology information resources, managed by the Radiological Society
of North America. It unifies and supplements other lexicons and standards, such as
SNOMED-Clinical Terms and DICOM.
• Content Standards
- Content standards define the structure and organization of the electronic message or
document’s content.
- For example, HL7’s Version 2.x (V2) (example): A widely implemented messaging
standard that allows the exchange of clinical data between systems. It is designed
to support a central patient care system as well as a more distributed environment

MDR Guide for Medical Device Software 50

 where data resides in departmental systems.
• Transport Standards
- Transport standards address the format of messages exchanged between computer
systems, document architecture, clinical templates, user interface and patient data
linkage.
- For example, Digital Imaging and Communications in Medicine (DICOM): The standard
for the communication and management of medical imaging information and related
data. DICOM enables the transfer of medical images across systems and facilitates
the development and expansion of picture archiving and communication systems.
- For example, Fast Healthcare Interoperability Resources (FHIR): An "Open Source"
HL7 standard for exchanging healthcare information electronically. The basic building
blocks of FHIR are “resources,” which describse exchangeable health data formats
and elements. HL7-FHIR resources can also be seen as content standards. FHIR also
provides standardization for application programming interfaces (APIs).
• Privacy and Security Standards
- Privacy standards aim to protect an individual's (or organization's) right to determine
whether, what, when, by whom and for what purpose their personal health
information is collected, accessed, used or disclosed. Security standards define a
set of administrative, physical, and technical actions to protect the confidentiality,
availability, and integrity of health information.
- For example, the General Data Protection Regulation (GDPR), in the Netherlands
called “AVG”, outlines privacy and security regulations for all processing and storage of
data relating to data subjects (or people) in the EU. This regulation extends to health
information and any organization that may process or store data on these subjects.
• Identifier Standards:
- Entities use identifier standards to uniquely identify patients or providers.
- For example, EUDAMED which stores Unique Device Identifiers.

5.11. IFUs, labels, brochures and website

5.11.1. IFUs and labels

• MDR Annex I: 23 Label and instructions for use

• MDR Annex I: 23.4 f MDSW and accessories selection
• MDR Annex I: 23.4 ab MDSW minimum requirements
• MDEG 2008-12- II-6.3 Mandatory Languages Requirements for Medical Devices
(aged)
• ISO 15223-1 Medical Devices — Symbols to be used with medical device labels,
labelling 6 and infor-mation to be supplied — Part 1: General requirements
• EN 1041 Information supplied by the manufacturer of medical device
• ISO 20417 Information to be supplied by the manufacturer
• ISO online browsing platform (OBP) Symbols
• IEC 82304-1 Health software requirements for product safety
• Medtech Europe Use of Symbols to Indicate Compliance with the MDR

The requirements for labels, packaging and Instructions for Use (IFU) are described in
MDR ANNEX 1 section 23. There are many additional requirements for labels and IFU’s
such as Implant Cards, but most are not applicable for MDSW. IEC 82304-1 contains
additional requirements for the IFU such as:

• Start-up and shut-down instructions (§ 7.2.2.5 & 7.2.2.6).

• Disposal instructions for the software in relation to Information Security and Privacy
(§ 7.2.2.9).
• IT Network specifications and risks (§ 7.2.3.2).

The use of symbols on the label as an alternative to written language is permitted in the

MDR Guide for Medical Device Software 51

 MDR regulation: Annex I: 23.1. h. There are 24 official languages in Europe, which creates
a necessity to translate the information provided on the labels into multiple languages.
This requirement can be dealt with by using symbols. The symbols which can or should
be used are described in ISO 15223-1. There is no good advice possible if these symbols
can be used, since the standard is not yet harmonized, although it is intended to become
a harmonized standard. As there is no similar standard, it is good practice to explain the
symbols in the IFU. The symbols can be found on the ISO online browsing platform (OBP).
Figuur 24
5.11.1 – Labels and Symbols
Figure. Label with the most common MDSW symbols.

Medical Device Software Name MD Medical Device Symbol

REF Catalogue number CE mark with Notified Body number

UDI UDI (= DI} (01) DI

Date of manufacture (= PI)

(10) PI in this case batch code
LOT Batch code (= PI}
(11) PI in this date of manufacture
SN Serial number (= PI)
(21) PI in this case serial number
Caution
Manufacturer
Translation
EC EC RPD Authorized representative
Consult instructions for use
Importer
Patient information website
Distributer

There are two types of barcodes used, linear code 128 or 2D data matrix barcodes. Linear
barcodes are more universal and can also be read by older and cheaper barcode scanners.
2D barcodes can contain much more content in much less space. 2D barcodes are the
preference but check your customers base if this is the case. Barcodes should be validated
Figuur 25 for their readability at the point of use. The barcode information needs to be next to
the6.1barcode
- ISO 13485 and MDR art 10
in human readable form. The different codes have a prefix, like (01) which
contains the DI, and which is also shown next to the corresponding UDI symbol.

The Instructions for use and labels need to be translated in the official languages of the
European Union, when that MDSAP
is required for a certain country (see MDEG 2008-12- II-
International
6.3, note: this document is not maintained). The translation requirement is not always
enforced for professionalISO
use. More information about that can be found on the websites
13485
of the EU member states.
class IIa / IIb / III
MDR art 10
class I
5.11.2. Promotional and informational materials
Process standards: CEN/TR 17223: material (i.e. brochures and websites)
The MDR IECdoes
62304not/ 82304
extensively discuss promotional
combine MDR art 10
and informational materials (i.e. scientific
IEC 62366 with ISOpublications
13485 and training materials). Only
handling of ISO
the 14971
claims is discussed in MDR art 7. There is a wide variety in promotional
ISO 14155
and informational materials, and it is wise to follow best practices. This will result in the
MDCG 2019-16
following information on or with those materials:

• (Trade) name of the device.

• Device identification details.
• Manufacturer registered name and address.
• CE mark and Notified Body number.
• Statement of the purpose of the material and the audience since this reduces the

MDR Guide for Medical Device Software 52

 liability. For example:” This clinical guide is to inform health care providers of the clinical
performance of the device”.
• The information should be relevant for the intended audience:
- Buyer of the device.
- Patient (as user) When applicable state that the instructions for use should always be
checked prior to the application of the device.
- Health care provider (as user). When applicable state that the instructions for use and
accepted (medical) guidelines should always be checked prior to the application of the
device.
- Service engineers. When applicable state that the service instructions should always
be checked prior to servicing the device.

A regulatory review on promotional materials brings regulatory and liability protection,

so it is beneficial, to give as much promotional and informational materials a regulatory
review. This is a popular area to ignore good advice, especially with press releases, most
large internationals have learned a hard lesson and now have good procedures in place.
Best practice review criteria are:

• Valid regulatory approval for specific country matching intended use and indications.
• Valid patient selection criteria if applicable.
• Valid product identification as submitted. Establishment names instead of brand names.
• No misleading product display, inks, quotes, references, or other information.
• No misleading information leading to potential patient injury (i.e. patient not seeking
proper medical advice from a licensed physician).
• Proper balance is between risks and benefits. The more promotional text, the more
information about risks, contra-indications, side-effects, etc.
• Valid (clinical) claims and if applicable validated or clinical evaluated (also called
substantiated). Statements about intended use and indications, safety, performance,
benefits and risks are seen as claims. Those close need evidence. The evidence is
reviewed in the Clinical Evaluation and the promotional material is reviewed if the
claims have adequate evidence.
• Common sense may be applied. A suggestion is also a claim.
• References to well recognized sources of scientific information:
- Clinical investigation (preferably randomized clinical trials).
- Meta-analysis of clinical investigations.
- Standards and guidance from organizations such as ISO, IMDRF, IEC, HL7, etc.
› Scientific peer reviewed publications and journals from well recognized (scientific)
bodies, such as WHO, IAEA, FDA, GEC/ESTRO, etc.
• No off-label use should be promoted.
• Proper division between branded (for the devices) and unbranded information (no
specific device mentioned, such as a meta-analysis for certain treatment options).
• Proper audience, communication channels and methods are used.
• Proper medical advice and procedures described, if applicable and if allowed to
communicate.
• Review if there is a risk for fines for (improper / unclear) claims or for off-label
promotion or comparison claims.

Articles must be from bona fide peer-reviewed journals or textbooks published by a

bonafide independent publisher. Articles must be in its original state. Must contain
disclosure statement for the right audience. Must disclose any relationship (including
financial) between the manufacturer, the product and authors. Scientific Guides/articles
must be separated from sales brochures. In general, it is good to separate branded from
unbranded information.

Off-label articles must be clearly marked “This information concerns a use that has not been
approved or cleared”. If the device is partially cleared, then it must include the approved
labelling as well. If an off-label use of the device is described in a paper written by a clinical
investigator(s), the paper may be distributed by a manufacturer only if it is provided in its
entirety. The off-label articles must contain a bibliography of other articles relating to the
new use. All significant risks or safety concerns known to the manufacturer concerning the

MDR Guide for Medical Device Software 53

unapproved use that are not discussed in the journal article or reference text.
Websites need to be reviewed as labelling. Use gateway page for location selection. For
instance, USA and outside USA. Indications only approved abroad must be segregated
from the USA site, with no hyperlinks between them, disclaimers are insufficient.
Do not link to off-label/unapproved information from within the website. Observe the
minimal “two clicks” rule for off-label information. Avoid hyperlinks to chat rooms or
sites known to discuss off-label use of the product. Provide notice that viewer is leaving
the website with a disclaimer: This hyperlink is for information purposes only, we do not
control, nor accept responsibility for the content of linked website.

Not approved information, pre-approval off-label information, including study

announcements, can be given, when it is in segregated in the investor or news section of
a website and/or distributed to the press concurrently with a newsworthy event. Including
both positive and negative results of clinical trials. An example website disclaimer is:
This website contains information about products which may or may not be available
in different countries and if applicable, may or may not have received approval or
market clearance by a governmental regulatory body for different indications for use.
Please consult individual country sites for approved use and any applicable restrictions.
Press releases issued by clinical institutions or investigators regarding off-label use
must not include statements or endorsements of the off-label use by anyone from the
manufacturer.

Trade show best practices:

• Sales trained in communicating within the intended use and indications.
• Sales trained in making permitted announcements (disclosures).
• Tradeshow promotional materials review used, including displays, etc.
• Sales handouts reviewed. No mix-up from branded and non-braded materials.
• Consider having clinical personnel present to respond to questions that are off label.
• Consider having separated spaces for cleared vs uncleared devices / USA vs
international sales.
• Uncleared devices:
- Not cleared demo model: Prominent statement of regulatory status (i.e. 510(k)
pending).
- (USA) Cannot make safety or performance claims.
- (USA) Cannot discuss product beyond the anticipated approval, to avoid post approval
off-label issues.
- (USA) Cannot take orders or discuss price. Can collect leads.
- Can explain intended use and features.
- Can discuss research or investigational use.

MDR Guide for Medical Device Software 54

Figuur 24
06 5.11.1 – Labels and Symbols

Quality Management System

Medical Device Software Name MD Medical Device Symbol

REF Catalogue number CE mark with Notified Body number

UDI UDI (= DI} (01) DI

6.1. Introduction
Date of manufacture (= PI)
(10) PI in this case batch code
LOT Batch code (= PI}
(11) PI in this date of manufacture
• MDR artSN10 General obligations
Serial number (= PI) of manufacturers
• ISO 13485 Medical devices – Quality Management(21) PI in this case serial number
Systems
Caution
• CEN/TR 17223 describes how to combine ISO 13485 and MDR art 10
Manufacturer
• IMDRF SaMD Translation
WG/N23 Software as a Medical Device (SaMD): Application of QMS
EC EC RPD Authorized representative
• Medical DeviceConsult
Single Audit for
instructions Program
use (MDSAP)
Importer
Patient information website
Distributer
Chapter 6 describes the QMS. ISO 13485 contains the requirements for a QMS of
Medical Devices. The QMS contains the procedures which describe the activities needed
to develop, purchase, produce, sell and service a MDSW. The QMS also describes the
organization of the Manufacturer and its external relations with amongst other suppliers,
importers and distributor. Evidence for the execution of the QMS activities have to be
documented in so-called Quality Records. In most cases the Notified Body audits the QMS
to review if the related MDR requirements are fulfilled.
Figuur 25
6.1 - ISO 13485 and MDR art 10

Figure 17 Quality Management System setup

MDSAP
International

ISO 13485
class IIa / IIb / III
MDR art 10
class I

Process standards: CEN/TR 17223:

IEC 62304 / 82304 combine MDR art 10
IEC 62366 with ISO 13485
ISO 14971
ISO 14155
MDCG 2019-16

A medical device quality management system (QMS) is a structured system of procedures

and processes covering the aspects of design, manufacturing, supplier management,
risk management, complaint handling, clinical data, storage, distribution, product
labelling, and more. This information is put in the quality manual, procedures (often called
SOPs), work instructions and templates. When the activities are performed, often an
administration has to be kept in quality records, to have evidence that the Quality System
was followed. The quality records are also used as input for other processes, such as risk
management and quality improvement processes.

Setting up a quality system for medical devices is a considerable effort, therefore often
a consultant is used. For start-ups it is recommended first to start with a minimum set of
procedures covering Design Control, Risk Management and Document Control & Records
Management.
MDR Guide for Medical Device Software 11

MDR Guide for Medical Device Software 55

 The quality system must meet the requirements of MDR art 10 for all risk classes. For risk
class IIa and higher the quality system in practice also needs to meet the requirements
of ISO 13485. The quality system is audited according ISO 13485 by a Notified Body. For
the international implementation of ISO 13485 an audit methodology is developed called
MDSAP (Medical Device Single Audit Program), which contains a set of standardized audit
questions. This methodology is often used by the Notified Body to certify the quality system.

6.2. ISO 13485 and MDR art 10

• MDR art 10 General obligations of manufacturers

• ISO 13485 ISO 13485 Medical devices - QMSs
• CEN/TR 17223 describes how to combine ISO 13485 and MDR art 10.
• IMDRF SaMD WG/N23 Software as a Medical Device (SaMD): Application of QMS
• Medical Device Single Audit Program (MDSAP)
• Recommendation NB-MED/2.5.2/Rec1 Subcontracting - QS related

The ISO 13485 has five sections with requirements that have to be implemented, for class
IIa devices and higher. For this the requirements of MDR art 10 have to be added. CEN/TR
17223 describes how to combine ISO 13485 with MDR art 10.

The following figure gives an overview of the Quality Management System:

Figuur 26
6.1 - ISO 13485 and MDR art 10
Figure 18 ISO 13485 Quality Management System

Customer requirements 5. Management

responsibility

4. Quality 7. Product realization Management Planning &

management commitment objectives
system
Policies Development Manufacturing Quality Management Management
Quality manual objectives review representative
Development Production
Medical device file planning planning

Control of Product Order

Performance

documents design processing

data

Control of records Process Purchasing

design & inspection

Verification & Production

6. Resource Validation & calibration 8. Measurement, analysis
management Monitoring data & improvement
Design Installation
Human resources Resources Transfer & servicing Monitoring and Internal
Risk mgt measurement audits
Infrastructure Regulatory Identification
approvals & Traceability Control of Corrective &
nonconforming preventive action
Complaint Regulatory
handling Reporting
Customer satisfaction

Figuur 27 6.4 - Economic Operators

The relevant ISO 13485 sections are:

Section Manufacturer
4: Quality Management
Placing on
System – This section containsLicense
general QMS
(+ €?)
requirements, as well the
as market
the documentation requirements. It includes the requirements
for the Quality Manual, Control of Documents, and Control of Records, all of which are
required documents
EC RPD in the QMS.
Authorized Rep
€ (+ license?)
MDR Guide for Medical Device Software App-store User 56

Manufacturer
Section 5: Management Responsibility – The management responsibility requirements
cover the need for top management to be instrumental in the implementation and
maintenance of the QMS. Along with planning for the QMS, there is a need for top
management to be involved in the ongoing review of the system to ensure customer
satisfaction and improvement.

Section 6: Resource Management – The section on management of resources covers

the necessity to control all resources, including human resources, buildings, and
infrastructure and the working environment.

Section 7: Product Realization – The product realization requirements deals with all
aspects of the planning and creation of the product or service. This section includes
requirements on planning, product requirements review, design, purchasing, creating
the product or service, and controlling the equipment used to monitor and measure
the product or service. ISO 13485 allows for requirements in the section to be excluded
if they are not applicable to the manufacturer (such as a manufacturer that does not
manufacture a product himself).

Section 8: Measurement, Analysis, and Improvement – This last section includes the
requirements needed to make sure that you can monitor whether your QMS is functioning
well. It includes assessing customer satisfaction, internal audits, monitoring products and
processes, dealing with non-conforming product, and corrective and preventive actions.

To complete the QMS, the requirements for a MDSW manufacturer have to be added:
• Guidance for this can be found in IMDRF SaMD WG/N23 Software as a Medical Device
(SaMD): Application of QMS.
• In addition, the requirements for the process development standards have to be added
for IEC 62304 / 82304 Software Development Life Cycle, IEC 62366 Usability, ISO
14971 Risk Management, MDCG 2019-16 Cybersecurity and if applicable ISO 14155
Clinical Investigation. Process development standards have to be followed from the
beginning of a software development project.

6.3. Person responsible for regulatory compliance (PRRC)

• MDR art 15 Person responsible for regulatory compliance

• MDCG 2019-7 Guidance on MDR art 15 on a PRRC
• Commission Recommendation 2003/361/EC of 6 May 2003 concerning the definition
of micro, small and medium-sized enterprises (OJ L 124, 20.5.2003, p. 36).

The Person responsible for Regulatory Compliance (PRRC) is responsible for compliance
with the MDR as described in MDR art 15, just like the Management Representative is
responsible for the Quality System Therefore those two functions will be often combined
in one person. The MDCG 2019-7 Guidance on MDR art 15 on a PRRC gives more
background information how to implement the PRRC function.

The PRRC has to be registered in EUDAMED, and the contact details are visible to the
general public. Therefore, it is advised to use a generic e-mail address and telephone
number. The PRRC can have personal liabilities, but this is arranged in the local legislation
arranging the implementation in each Member State. When there is more than one PRRC
the division in responsibilities shall be described. Small and Medium Enterprises (SME’s)
may outsource the PRRC function. A SME has less than 50 employees and less than 10
Million Euro turnover.

The table below shows the PRRC responsibilities and to what sections of the MDR these
responsibilities relate:

MDR Guide for Medical Device Software 57

Table 13 PRRC responsibilities

MDR art 15.3 PRRC responsibilities Related MDR sections

•T
 he conformity of the devices is • MDR art 10(9): Establish, document, implement, maintain, keep up to date
appropriately checked, in accordance and continually improve a quality management system that has to ensure
with the QMS under which the devices are compliance with the MDRs in a manner that is proportionate to the risk
manufactured, before a device is released class and the type of device.
• Note: MDR art 10(9): describes in detail what quality management aspects
has to be addressed.
•T
 echnical documentation and is drawn up • MDR arti 10(4) Draw up and keep up to date technical documentation
and kept up to date according MDR Annex II and III.
• MDR Annex II Technical Documentation
• MDR Annex III: Technical Documentation on Post-Market Surveillance

• E U declaration of conformity is drawn up • MDR art 10(6) Draw up an EU declaration of conformity see MDR art 19 and
and kept up to date affix the CE mark see MDR art 20.
• MDR art 19 EU declaration of conformity
• MDR Annex IV: EU Declaration of Conformity (DoC)
•N
 ote: CE marking is a consequence • MDR art 20 CE marking of conformity
of drawing up the EU declaration of • MDR Annex V: CE marking of conformity
conformity
•P
 ost-market surveillance obligations are • MDR art 10.10. Post market surveillance system in accordance with MDR
complied with in accordance with MDR art 83.
art 10 (10) •MDR art 83 Post-market surveillance system of the manufacturer
•R
 eporting obligations referred to in MDR • Article 10(13) System for recording and reporting of incidents and field
art 87 to 91 are fulfilled safety corrective actions see MDR art 87 and 88.
• MDR art 87 Reporting of serious incidents and field safety corrective
actions
• MDR art 88 Trend reporting
• MDR art 89 Analysis of serious incidents and field safety corrective actions
• MDR art 90 Analysis of vigilance data
• MDR art 91 Implementing acts
• F or investigational devices, the statement • MDR Annex XV chapter II (4.1). A signed statement for the investigational
referred to in MDR Annex XV chapter II device that the device conforms to the GSPR.
(4.1) is issued.

6.4. Economic Operators

• MDR art 5 Placing on the market and putting into service

• MDR art 6 Distance sales
• MDR art 11 Authorized representatives
• MDR art 12 Change of authorized representative
• MDR art 13 General obligations of importers
• MDR art 14 General obligations of distributors
• MDR art 16 Cases in which obligations of manufacturers apply to importers,
distributors or other persons
• EU: Blue guide: The ‘Blue Guide’ on the implementation of EU products rules
• EU: Factsheet for Authorized Representatives, Importers and Distributors of Medical
Devices
• EU: Factsheet for Procurement Ecosystem of medical devices
• EU: SANCO/B/2/PBE/pdw Ares(2010) 332016 interpretative document of the
commission's services plac-ing on the market of medical devices
• HPRA: Guide for Distributors of Medical Devices
• COCIR: Position Paper Economic Operators under the Medical Device Regulation
• COCIR: Template for Suspected Incident Form for Trade Partners
• MedTech Europe: Questions & Answers on Economic Operators to support IVDR/MDR
implementation

MDR Guide for Medical Device Software 58

 Development Production
Medical device file planning planning

Control of Product Order

Performance
documents design processing

data
Control of records Process Purchasing
design & inspection

Economic operators play an important

6. Resource role& how MDSW
Verification Productionis sold and serviced within the
8. Measurement, analysis
Validation & calibration
management
EU. The requirements are based on the Blue guide and further detailsdata
Monitoring are given in& the improvement
MDR. For MDSW theResources Design
requirements are not Installation
intuitive. Each Economic Operator has to
Human resources Transfer & servicing Monitoring and Internal
meet certain MDR requirements, so identifying the Economic Operator Risk mgt
rolesmeasurement
is important. audits
Infrastructure Regulatory Identification
Economic operators are manufacturers (MDR art
approvals
10), authorized representatives
& Traceability Control of Corrective &
(MDR art 11 and 12), importers (MDR art 13), distributors (MDR art 14), and nonconforming system & preventive action
procedure packers (MDR art 22). Economic operators need to register themselves (MDR Regulatory
Complaint
art 31), except for distributors, and systemCustomer procedure packers, which depends on the Reporting
& satisfaction handling

Competent Authority where the distributor and system & procedure packers is located.
The COCIR Position Paper on Economic Operators under the Medical Device Regulation
provides more details.

Figuur 27 6.4 - Economic Operators

Figure 19 Economic Operators

Manufacturer
Placing on License (+ €?)
the market

EC RPD

Authorized Rep
€ (+ license?)
App-store User

Manufacturer

Placing on Making License (+ €?)

the market available
Importer Distributer

An importer, distributor or procedure packer who changes a Medical Device or it’s

intended use, becomes a Manufacturer (MDR art 16). Those changes include selling a
Medical Device under its own name or changing to the intended use or the Safety and
Performance of a Medical Device. In that case also a QMS is needed. A Manufacturer, who
is outside the EU, needs an Authorized Representative and an importer.

When a manufacturer is using a distributor, an agreement is needed. Below are the

requirements for a distributor:
MDR Guide for Medical Device Software 12

• Check whether the medical device has a valid CE marking.

• Check that the UDI is on the label (from May 2021 for Class III, May 2023 for Class IIa /
IIb and May 2025 also for Class I).
• Check whether the manual and label contain the correct information.
• Check whether the importer complies with the requirements.
• Store and retain the device according to the manufacturer's instructions.
• Inform the manufacturer (and possibly the importer and authorized representative) and
if necessary, the Competent Authority if there are complaints or something is wrong
with the device. COCIR has developed a Template for this: Suspected Incident Form for
Trade Partners.
• Keeping a complaint register.
• Cooperate with any corrective actions (e.g. withdrawal from the market in the event of
a recall).
• Cooperate with inspections (e.g. by showing documentation and providing samples).

The MDR art 6 on distant sales does not address the function of App-stores and SaaS
business models. Using App-stores is a challenge:
• If App-stores operate as resellers they need to fulfil the operator roles of Importer or
Distributor where necessary. App-stores as resellers can place a MDSW on the market

MDR Guide for Medical Device Software 59

 or make it available for use. App-stores in general do not want to operate as distributor
and become an Economic Operator, since they then need to meet the requirements of
the MDR.
• If App-stores operate as a marketplace, they assist in financial transactions and
warehousing the MDSW app. In this role the App-store is not an Economic Operator
but becomes a supplier of services. The manufacturer is then providing the license and
needs an importer and distributor for this, if the manufacturer is out-side the EU. For a
manufacturer having an App-store as critical supplier is a challenge, since then a quality
agreement is needed that a Notified Body can audit them.

A manufacturer can place MDSW on the market. A manufacturer outside the EU needs an
Authorized representative and Importer to place MDSW on the market. A MDSW which
has not yet passed customs is not yet placed on the market. MDD/AIMDD stock placed on
the market before 26 May 2024 in the supply chain at the importer or distributor can be
sold or put into service (MDR art 120 (4)) until 26 May 2025.

6.5. UDI (traceability) and EUDAMED

6.5.1. UDI introduction

• MDR art 27 Unique Device Identification system

• MDR art 28 UDI database
• MDR Annex VI UDI database
• MDCG 2018-1 Guidance on Basic UDI-DI and changes to UDI-DI
• MDCG 2018-3 Guidance on UDI for systems and procedure packs
• MDCG 2018-4 Definitions/descriptions and formats of the UDI core elements for
systems or procedure packs
• MDCG 2019-1 MDCG guiding principles for issuing entities rules on Basic UDI-DI
• EU UDI system frequently asked questions and answers
• MedTech Europe’s Guidance on Basic UDI-DI Assignment
• HL7 ANSI/HL7 UDI, HL7 Cross Paradigm Implementation Guide: UDI Pattern

The Unique Device Identification (UDI) code is used to identify a Medical Device. Its main
purpose is to identify a Medical Device uniquely. This is extremely important when a recall
or warning of the product has to take place. Keeping track of Medical Device production
and use is called traceability. The UDI also has many secondary uses, like managing the
logistical flow or stock.

The UDI will be globally implemented, however, each regulatory country or economic area
has its own implementation, which causes small differences. In this guide the European
MDR implementation for UDI will be discussed, considered that the Medical Devices
also can be exported. The UDI code will be publicly available through registration in the
EUDAMED database.

The USA Food and Drug Administration (FDA) implemented requirements for UDI in 2013.
The FDA requirements deviate slightly from the MDR requirements for UDI. When there
are export plans to the USA, it is good to study first the differences, which can be difficult
to implement at a later stage.

The provisions for the European UDI system are defined in Art. 27, 28, 29 and 31 as well
as in Annex VI of the EU MDR. Further explanation of the use of UDI and EUDAMED can
be found in:
• MDCG 2018-1 v3 Guidance on Basic UDI-DI and changes to UDI-DI.
• EUDAMED database final data elements under the Basic UDI-DI:
- MDCG 2018-3 Guidance on UDI for systems and procedure packs.
- MDCG 2018-4 Definitions/descriptions and formats of the UDI core elements for
systems or procedure packs.

MDR Guide for Medical Device Software 60

 - MDCG 2019-1 MDCG guiding principles for issuing entities rules on Basic UDI-DI.
- MDCG 2019-4 Timelines for registration of device data elements in EUDAMED.
- MDCG 2019-9 Summary of safety and clinical performance A guide for manufacturers
and notified bodies.
• European Commission: UDI system frequently asked questions and answers.
• Regulation (EU) 2017/2185 Commission Implementing Regulation (EU) 2017/2185 on
the list of codes and corresponding types of devices for the purpose of specifying the
scope of the designation as notified bodies in the field of medical devices.
• MedTech Europe guidance for assigning Basic UDI-DI.

The issuing entities have submitted their own guidance which can be found on their
websites:
GS1 https://www.gs1.org/
IFA https://www.ifaffm.de/en/home
HIBC https://www.hibcc.org/
ICCBBA https://www.iccbba.org/

6.5.2. UDI system overview

To make the UDI code work a whole system is created:

Figuur 28 Figure
6.5.2. 20 UDI
UDIsystem
system overview
overview

Issuing entity Importer

SRN
Basic-UDI-DI
UDI-DI
Authorized Rep
SRN

Distributer
Manufacturer; UDI-DI
Procedure packer UDI-PI Health care
Barcode provider
Basic-UDI-DI
SRN UDI-DI

EUDAMED
Actor Module UDI / Device
(ACT) Module (UDID)

• S RN & EUDAMED Actor Module: The manufacturer (or procedure packer) must be
Figuur 29 uniquely
6.5.5 – EUDAMED identified
modules with an SRN (Single Registration Number). The manufacturer
registers via the Competent Authority in the EUDAMED Actor Module and receives
the SRN. The SRN will appear for instance on each Declaration of Conformity and CE
certificate. EUDAMED
• Basic-UDI-DI: Each Medical Device model of a manufacturer must be uniquely identified
with
ActoraModule
Basic-UDI-DI
(ACT) UDI / DeviceDevice
(Basic-UDI Module Identifier).
Certificates
A /Basic-UDI-DI
Notified is used to group one
(UDID) Body Module (CRF)
or more Medical Devices, MDSW modules or Accessories, thus the Basic-UDI-DI is
used
Clinicalto group one
Investigation / or more UDI-DI’s. The manufacturer requests the Basic-UDI-DI at
Performance Market Surveillance
Studies The Basic-UDI-DI
Module (MSU) is usedVigilance
an issuing entity. to group Module (VGL) Medical Devices from a
similar
Module (CIPS)
certain manufacturer. The Basic-UDI-DI will appear for instance on each Declaration
of Conformity and CE certificate, but it will not appear on the Medical Device product
label. Note: A Basic-UDI-DI connects devices with same intended purpose, risk class
and essential design and manufacturing characteristics. A change in intended purpose,
Figuur 30 6.6: MDR implementation dates and deadlines
risk class, essential design or manufacturing characteristics, usually results in a new
Basic-UDI-DI.
• UDI-DI: Each commercially available System, Medical Device, Module or Accessory of
a26manufacturer
May 2021 must
26 be uniquely
Nov 2022 26 May identified
2023 with
26 May an
2024UDI-DI. Any2025
26 May change to the data
elements relating to the medical device (e.g. trade name, product version, or model)

MDRforfully
MDR Guide Medical Device Software 61
applicable
 may require a new UDI-DI to be assigned. The manufacturer requests the UDI-DI at an
issuing entity and receives a range of numbers for the UDI-DI. A change in the data
elements relating to the medical device (e.g. trade name, product version, or model)
usually results in a new UDI-DI. For software there are specific requirements, see next
paragraph.
• EUDAMED UDI / Device Module: The manufacturer (or procedure packer) must submit
the Basic-UDI-DI and UDI-DI to the UDI / Device Module into EUDAMED. In EUDAMED
it’s attributes are linked to the Basic-UDI-DI and UDI-DI. This data has to be added to
EUDAMED and has to be maintained by the manufacturer.
• Nomenclature code: The nomenclature code is to identify what type of Medical Device
the UDI-DI is. For instance,” Radiation Treatment Planning Software”. The manufacturer
can determine the nomenclature when maintaining the UDI-DI in EUDAMED. Each UDI-
DI has a nomenclature code.
• UDI-PI: The UDI-DI is created by the manufacturer for each lot number or serial number
of a device. For MDSW the UDI-PI contains the software version.
• UDI: An UDI consists of an UDI-DI + UDI-PI. The UDI appears on the product label.
Economic actors and health care providers, which get in contact with the product
throughout the supply chain, register the UDI number. This registration allows for
traceability.
• Issuing entity: The EU Commission has officially designated the following issuing
entities: GS1, HIBCC, ICCBBA and IFA GmbH. These organizations have developed
standards for the uniform use of machine-readable information such as identification
keys, data attributes and barcodes. An example of the UDI-DI is the GS1 GTIN (Global
Trade Item Number).

Below are the main attributes linked to the codes above of which most have to be
maintained in EUDAMED:

Table 14 EUDAMED attributes

Basic UDI-DI: UDI-DI:

- Notified Body - UDI-DI value
- Type, number and expiry date of the certificate - Quantity per package
issued by the notified body - Basic-UDI-DI
- SRN - Additional UDI-DI
- Name /address of manufacturer - Reference /catalogue number
- Devices manufactured by another legal person - Device model
- Member State in which the device has been placed - Direct marking (y/n)
on the market in the Union - Unit of use UDI-PI
- Class IIa, class IIb or class III devices: Member - Type of UDI-PI’s)
States where the device is or is to be made - Name and address of the manufacturer
available - SRN
- Risk class of the device - Name and address of the authorized representative
- Measuring function (y/n) - Nomenclature code
- Implantable (y/n) - Risk class
- Active device (y/n) - Name/trade name
- Identification number or link to electronic system - Additional product description
of clinical investigations - Clinical size
- Specification as to whether the intended purpose - Storage /handling conditions
of the device is other than a medical purpose - Information labelled in accordance with Section 10.4.5 of Annex I
- Class III products /implants: summary of safety - URL for additional information (eIFU, etc.)
and clinical performance - Critical warnings /contra-indications
- Status of the device - Status of the device
- Systems /procedure pack: UDI-PI
- Systems /procedure pack: Indication

UDI-PI: SRN:
- Serial number /lot number - Type of economic operator (manufacturer, authorized
- Expiry date representative, or importer)
- Manufacturing date, if expiry date is not - Company name, address and contact details
applicable - Name address and contact details of the PRRC (person responsible
for regulatory compliance)

MDR Guide for Medical Device Software 62

The following table gives an overview of the main places where the SRN, Basic UDI-DI and
UDI (UDI-DI + UDI-PI) are used:

Table 15 SRN, Basic UDI-DI and UDI (UDI-DI + UDI-PI)

Place of use SRN Basic UDI

UDI-DI (UDI-DI + UDI-PI)
Manufacturer Art. 30 (1)
Authorized Rep Art. 30 (1)
Importer Art. 30 (1)
Declaration of Conformity Art. 27 (6) Art 27 (6)
Conformity assessment certificates v v
Certificate of free sale Art 60 (1)
Technical Documentation: Product Annex II 1.1b
description and specification
Product registration Art 29 (1-4) Art 29 (1-4)
Technical documentation: information to v
be supplied by the manufacturer, up-to-
date List
Reporting of serious incidents and field v v
safety corrective actions
EU technical documentation assessment v
certificate
EU type-examination certificate v
EU product verification certificates v
Summary of safety and clinical Art 32 (2a) Art 32 (2a)
performance (Class III)
Implant card for Patients Art 18 (1)
Clinical trials documents recommended
Vigilance reporting recommended
Hardware product: the UDI and related Part C Annex VI
information needs to be on the “UDI
carrier” (barcode-label). The barcode
label needs to be on the product and the
product packaging. The label contains:
•m achine readable information (according
to the barcode format received from the
issuing entity)
• human readable information
Software product • Annex VI part C 6.5
• MDCG 2018-5 UDI
Assignment to MDSW

6.5.3. UDI for MDSW

For UDI used with MDSW there are specific requirements in Annex VI Part C and MDCG
2018-5:
• The UDI (UDI-DI + UDI-PI) is usually given at system level of the software if the intended
use and risk class is the same.
• The software identification on the label is part of the UDI-PI.
• After certain software changes a new UDI-DI must be assigned.
• The human-readable form can be stored in software menus. If there are no user
interface other ways have to be used, e.g. an application programming interface (API).
• The UDI-DI changes when:
• Any change of the basic UDI-DI.
• Any changes which impact the original performance, safety, or the interpretation of
data.

MDR Guide for Medical Device Software 63

 • A
 change to the name or trade name, version or model number, critical warnings or
contra-indications, user interface language requires a new UDI-DI.

Minor software revisions, e.g. bugfixes without relation to safety and security, require a
new UDI-PI and not a new UDI-DI.

6.5.4. EUDAMED introduction

• MDR art 29 Registration of devices

• MDR art 31 Registration of manufacturers, authorized representatives and importers
• MDCG 2019-4 Timelines for registration of device data elements in EUDAMED
• MDCG 2021-1 Guidance on harmonized administrative practices and alternative
technical solutions until EUDAMED is fully functional
• EU EUDAMED database final data elements under the Basic UDI-DI
• EU Regulation 2017/2185 Commission Implementing Regulation (EU) 2017/2185 on
the list of codes and corresponding types of devices for the purpose of specifying the
scope of the designation as notified bodies in the field of medical devices.

Figuur 28 6.5.2. UDI system overview

EUDAMED stands for “European Database for Medical Devices”. This database is managed
by the European Commission and contains all relevant information on medical devices on
the EU market. Issuing entity Importer
SRN
Basic-UDI-DI
“EUDAMED aims to improve market surveillance by givingUDI-DI competent authorities swift
access to information about manufacturers and their authorized representatives,
Authorized Rep
products and certificates,
SRN and vigilance data, it should also contribute to the exchange
of information on clinical examination data and the consistent application of the above
directives, in particular with regard to reporting requirements.” Distributer
Manufacturer; UDI-DI
The traceability ofProcedure packer facilitated by
medical devices, UDI-PI
EUDAMED, should improve
Healththe
care
Barcode provider
effectiveness of recalls and other field actions, incident reporting and market surveillance.
Furthermore, positive
SRN
impactsBasic-UDI-DI
on the reduction of product counterfeiting, the reduction
UDI-DI
of medical malpractice and the procurement, storage and disposal of medical devices are
expected.
EUDAMED
Actor Module UDI / Device
6.5.5. EUDAMED database
(ACT) structure overview
Module (UDID)

The EUDAMED database consists of 6 interconnected databases. Manufacturers, other

Economic Operators, Notified Bodies, Competent Authorities and each can maintain certain
parts of the data contained in EUDAMED. EUDAMED contains the following modules:
Figuur 29 6.5.5 – EUDAMED modules
Figure 21 EUDAMED database structure overview

EUDAMED

UDI / Device Module Certificates / Notified

Actor Module (ACT) (UDID) Body Module (CRF)

Clinical Investigation /
Performance Studies Market Surveillance Vigilance Module (VGL)
Module (CIPS) Module (MSU)

• A
 ctor Module (ACT). In the Actor module, Economic Operators have to register. This
Figuur 30
registration goes via the Competent Authority who does the validation of the Economic
6.6: MDR implementation dates and deadlines
Operator. In the Netherlands Farmatec/CIBG has that role. After validation, the

MDR Guide for Medical Device Software 64

26 May 2021 26 Nov 2022 26 May 2023 26 May 2024 26 May 2025
 Competent can give the Economic Operator the SRN (Registration Number).
UDI / Device Module (UDID). The UDI/Device Module does contain all device-specific
information and have the same functions as the comparable database of the American
Health Authority (FDA) GUDID. The main difference to the GUDID is that the UDI data is
divided into two areas BASIC UDI-DI and the UDI-DI. Manufacturers and other economic
operators are responsible for maintaining all their Basic-UDI and UDI-DI attributes.
• Certificates/Notified Body Module (CRF) – Any medical device distributed in Europe
and reviewed by a Notified Body requires a CE certificate. These certificates are stored
and managed in this module.
• Clinical Investigation/Performance Studies Module (CIPS) This module contains the
information from pre and post market clinical studies and is also used by the competent
Authorities to share information and coordinate their activities.
• Vigilance Module (VGL) This module contains all information related to serious
incidents. Manufacturers need to vigilance report those incidents, provide summaries
thereof in PSUR’s (Periodic Safety Update Reports) and provide TR’s (trends reports).
Follow-up actions like Field Safety Corrective Action (FSCA) and Field Safety
Notifications, also need to be reported. The competent Authorities file their assessment
reports of the Manufacturers actions.
• Market Surveillance Module (MSU). In this module the results of the market surveillance
are reported, like inspection reports of Economic Operators and yearly analysis reports
on the safety of the Medical Devices on the market. Based on those reports’ actions can
be initiated to improve the situation.

6.6. MDR, EUDAMED and Trade Agreements in transition

MDR art 120 Transitional provisions

MDR art 123 Entry into force and date of application
MDCG 2019-4 Timelines for registration of device data elements in EUDAMED
MDCG 2020-3 Transitional provisions on significant changes of MDD or AIMDD devices
MDCG 2019-10 Transitional provisions on validity of certificates of MDD or AIMDD
devices
MDCG 2020-2 Transitional provisions of class I art 120(3, 4)
MDCG draft Guidance on appropriate surveillance according to MDR art 120(3)
MDCG 2021-6 Q & A on clinical investigation

The MDR came into force on 25 May 2017. In a four-year transition period until 26 May
2021, it replaces both the MDD and the AIMDD. It is possible to have for the same device
both an MDD/AIMDD and an MDR certificate. The manufacturer must register the Basic-
UDI and UDI-DI including the attributes in EUDAMED. The implementation dates for
direct marking with the UDI-DI and UDI-PI on the product depends on the risk class. The
manufacturer cannot apply for the assignment of an UDI art. 27 (3) before EUDAMED is
ready.

After 26 May 2021 making significant changes to MDD and AIMDD devices is no longer
possible, causing additional problems for MDSW with its short development cycles. A
significant amount of MDSW devices will be up classified because of classification rule 11.
Causing new requirements like the need for a Notified Body or Clinical Investigations.
An overview on the important implementation dates and deadlines is given below and can
be seen in the figure below:
• 26 May 2017:
- MDR has come into force MDR compliant can be placed on the market see MDR art
120 (5). This also applies to custom-made products see MDR art 2 (3) and systems and
procedure packs see MDR art 2 (10-11). MDR class Is, Im, Ir, class IIa and higher need
an MDR designated see MDR art 120 (6).
• 13 March 2019 Compendium I:
- No significant changes.
• 13 November 2019 Compendium II:

MDR Guide for Medical Device Software 65

 - Introduction of a transition period for class I devices.
• 26 May 2021 (Date of Application):
- MDR: The MDR is fully applicable and the MDD / AIMDD are no longer applicable.
Notified Bodies only may submit MDR CE certificates.
- MDD / AIMDD certified devices: may still be placed on the market, with a valid CE
Figuur 28 6.5.2. UDI
certificate art.system
120overview
(2). Class I devices need to have a valid Declaration of Conformity
from before 26 May 2021 see Compendium II. The QMS has to meet the requirements
of MDR art 10. No significant changes to the device and intended purpose can be
made art. 120Issuing(3). Aentity
significant change as result SRN Importer
of a corrective measure, can be
implemented if accepted by the competent authority. Basic-UDI-DI
UDI-DI
- MDD / AIMDD guidance like the MEDDEV’s and NBOG’s are no longer
Authorized Rep applicable.
However not SRNhaving them would lead to serious holes in the guidance. When using
them, it is advised to review them on where the differencesDistributer are with the MDR and give
a justification,Manufacturer;
why they can be used.
UDI-DI
- MDD / AIMDD harmonized
Procedure packer standardsUDI-PIhave hardly any replacements
Health care under the MDR,
in addition most of them aged. It is advised Barcode in general to use the most recent standard
provider
and provide Basic-UDI-DI
a justification, why they can be used. The FDA recognized standard
SRN UDI-DI
database is a good starting point for finding the most applicable standards.
- EUDAMED: Basic-UDI and UDI-DI information including their attributes can be put in
EUDAMED
EUDAMED art 123 (3e).
Actor Module UDI / Device
- UDI: class III products (ACT)need to be marked
Module art 123 (3f).
(UDID)
- Clinical Investigations that started before 26 May 2021 may continue after this date
art. 120 (11). However adverse event reporting and device deficiencies need to be
performed according to the MDR.
• 26 November 2022:
Figuur 29 - EUDAMED: Basic-UDI
6.5.5 – EUDAMED modules and UDI-DI information is required to be available MDR art 123

(3e).
• 26 May 2023:
- UDI: class IIa / IIb products need to be UDI marked art 123 (3f).
EUDAMED
• 26 May 2024
UDI / Device Module
- MDD Actor
/ AIMDD
Modulecertificates
(ACT) expire, and thus areCertificates
(UDID) no longer
Body
/ Notified
Module allowed
(CRF) to be sold.
• 26 May 2025:
- UDI:Clinical
class Investigation
I products/needMarket to beSurveillance
UDI marked art 123 (3f).
- MDDPerformance
/ AIMDD Studies
stock
Module (CIPS) placed on the(MSU)
Module market beforeVigilance
26 Module (VGL) may no longer be sold
May 2024
or put into service art 120 (4).
• 26 May 2027:
- Start coordinated assessment procedure for Clinical Investigations art 123(3h)
Figuur 30 6.6: MDR implementation dates and deadlines
Figure 22 Implementation dates and deadlines

26 May 2021 26 Nov 2022 26 May 2023 26 May 2024 26 May 2025

MDR fully
applicable

MDD/AIMDD no MDD/AIMDD
new certificates MDD/AIMDD
certificates
allowed deadline stock deadline

EUDAMED UDI EUDAMED

module UDI module
available deadline

UDI class III UDI class IIa/b UDI class I

direct marking direct marking direct marking

MDR Guide for Medical Device Software 13

MDR Guide for Medical Device Software 66

The transition to the MDR requires special attention for the existing trade relations, such
as Mutual Recognition Agreements. The relation for the United Kingdom and Switzerland
is insecure, and it is likely they become WTO Third Countries. These changes can cause
changes in the labelling, the invalidation of MDD / AIMDD certificates or the non-
availability of a Notified Body. Concessions for these situations have to be given by the
National Competent Authority, and in general a concession is no longer than 6 months.

6.7. Post Market obligations

6.7.1. Post Market Surveillance and Post Market Clinical Follow-Up

Post-Market Surveillance (PMS):

• MDR art 83 PMS system
• MDR art 84 PMS plan
• MDR art 85 PMS report
• MDR art 86 Periodic Safety Update Report (PSUR)
• MDR art 92 Electronic system on vigilance and on post-market surveillance
• MDR Annex III Technical documentation on PMS
• ISO/TR 20416 PMS
• Setting up PMS (original title: Vormgeven PMS voor medische hulpmiddelen onder de
MDR en de IVDR)

Post-Market Clinical Follow-up (PMCF) and Registries:

• MDR art 61(11) PMCF
• MDR Annex XIV part B PMCF
• MDCG 2020-7 Guidance on PMCF plan template
• MDCG 2020-8 Guidance on PMCF evaluation report template
• IMDRF Registry WG/N46 Tools for Assessing the Usability of Registries in Support of
Regulatory Decision-Making
• IMDRF Registry WG/N42 FINAL:2017 Methodological Principles in the Use of
International Medical De-vice Registry Data

The MDR uses the terms post-market surveillance (PMS), vigilance and market
surveillance. Since any of these terms are also often used for all three activities
combined, this is a source of confusion. Even more confusion is caused by the significant
overlap of PMS with post-market clinical follow up. And the overlap of Clinical Evaluation
with Post-Market Clinical Follow-Up. And the association of Post Market Clinical Follow
Studies with Clinical Investigations.

The European database EUDAMED is going to contain vigilance and PMS information.
The information contained in EUDAMED is going to be transparent to the general public.
Therefore patient and employee privacy has to be protected according to the GDPR in
the vigilance and PMS process. It is also recommended that the information which will be
stored in EUDAMED is screened for trade secrets.

The terms can be explained as follows:

• Post Market Surveillance (see MDR art 83 and ISO/TR 20416 Post-market surveillance)
- Post-market surveillance (PMS) aims to monitor the safety and performance and
to improve the quality of the device once it is placed on the market. Some safety
and performance risks only become apparent when the devices are used, stored,
transported or cleaned. Continuous and systematic post-market surveillance is
therefore crucial to prevent uncontrolled risks as a result of defects or undetected
security issues.
• Vigilance (see MDR art 87)
- Vigilance is the reporting of serious incidents and field safety corrective actions by
manufacturers to the relevant competent authorities. The timescale for reporting
depends on the severity of the serious incident. In addition, trends in expected

MDR Guide for Medical Device Software 67

 undesirable side effects and incidents that are not classified as serious have also be
reported.
• Market Surveillance (see MDR art 93)
- Market surveillance is performed by the Competent Authorities to check that the
devices on the market comply with the MDR and are not a health or safety threat.

The following table shows which documents are required per risk class:

Table 16 PMS related documentation per device risk class

MDR risk Post Market Post Market Periodic Post Market Post Market Clinical
class Surveillance Surveillance Safety Update Clinical Fol- Follow-Up
Plan Report Report low-Up Plan Report
Class I √ √ - √ If no report,
Justification required
Class IIa √ - ≤ 2yr √ If no report,
Justification required
Class IIb - √ - ≤ 1yr √ If no report,
implantables Justification required
Class III + √ - ≤ 1yr √ If no report,
implantables Justification required

The following figure shows how the acceptance criteria of PMS, PMCF and Clinical
Evaluation relate to each other. Unfortunately, a Clinical Evaluation and PMS has to
contain all applicable information for the reviewer, which is a challenge for not duplicating
to much information from the Clinical Evaluation, PMS and PMCF.
Figuur 32 6.6: MDR implementation dates and deadlines
Figure 23 Acceptance criteria from Clinical Evaluation, PMS and PMCF.

Quality data: Can the Post Market Surveillance

device be improved?

Post Market Clinical

Clinical Evaluation Follow Up

(Claimed) benefits: Clinical evidence:

Positive impact on health? Sufficient?

Safety: No unacceptable Safety: New emerging risks

risks or side-effects? or unknown side-effects?

(MDSW) Performance: Miasuse / off-label use:

Meet intended purpose? Correct intended purpose?

MDSW Clinical State of the Art:

Association: Valid? Changed?

• Post-market surveillance plan (see MDR art 84 and Annex III 1.1)
- PMS is undertaken in accordance with a PMS plan. The PMS plan Is when applicable
Figuur 33 coordinated with
6.7.2: Complaint authorized
Handling representatives,
and Vigilance reporting importers, and distributors. The
contents of the PMS plan are described in MDR Annex III. The PMS plan describes
which data to collect, how to analyze the data and the resulting risks, how to
implement improvements and how to communicate with competent authorities, MIR Form
notified bodies, economic operators, and users. MEDDEV 2.12
- The PMS plan has to describe the methods for data gathering and analysis. The
Field Safety Notice
objectives of the PMS plan have to have acceptance criteria. The post-market MDR surveillance
art 87
plan shall identify which information sources (see Annex III 1.1a) have to be used:
› Serious incidents, and field safety corrective actions.
Reporting
Field Safety Corrective
Complaint Action MDR art 87
› PSUR, and serious adverse
Feedback events if applicable.
Handling
MDR art 87
ISO 13485-8.2.1 MEDDEV 2.12
› Non-serious incidents, undesirable side-effects,
ISO 13485-8.2.2 and informationPeriodic
ISO 13485-8.2.3 from Safety
trendReport
reporting (see MDR art 88). MDR art 87
2 – 15 days
Adverse event reporting
MDR art 80
MDR Guide for Medical Device Software 68

Trend Report
MDR art 88
 › F eedbacks and complaints, provided by users, distributors, and importers.
Feedbacks from information sources such as:
- Non-solicited observations by healthcare providers.
- Observations by the organization’s sales and marketing teams.
- Service reports or maintenance reports.
- Regulatory compliance notifications.
- The post-market surveillance plan shall also identify pro-active data collection
methods. Pro-active data collection is often planned in a PMCF plan. When no PMCF
is performed, a justification has to be given. The following methods are pro-active:
› Surveys.
› Literature searches.
› Analyzes of registries.
› Analyses of Vigilance and Field Corrective Action information from similar (and
competitor) medical devices which can be found at regulatory agencies, such as in
the MAUDE database from the FDA and EUDAMED in the near future.
› Post-market clinical follow-up studies.
- The data analysis needs to be performed (MDR art 83 (3)):
› To update benefit - risk ratio determination and improve risk management.
› To update design, manufacturing, and service information, IFU and labelling.
› To update clinical evaluation.
› To update SSCP for class III and implantable devices.
› To identify needs for preventive, corrective or field safety corrective action.
› To identify improvements for usability, performance and safety of the device.
› To contribute to the post-market surveillance of other devices if applicable.
› To detect undesirable side effects that could be an unacceptable risk. These are
reportable, unless they are:
- Identified in the labelling.
- Clinically well-known and predictability.
- Documented with a risk assessment prior to the occurrence of the incident.
- Clinically acceptable in terms of the individual patient benefit.
- Reviewed by a qualified assessor.
- Detection of trends (see MEDDEV 2.12/1) in the defined observation period in
frequency or severity of incidents that might lead to a significant negative impact on
the benefit-risk analysis ratio as defined in the clinical evaluation. These trends are
reportable.
- Traceability and interfaces to other processes have to be clearly defined, such
as to PMCF, risk management, vigilance reporting, clinical evaluation, corrective
and preventive actions, and the implementation of improvements in the QMS,
development, production, sales and service (see MDR art 83 (3).
- The PMS plan needs to contain vigilance reporting criteria (see MDR art 83 (4), and
reference to procedures to fulfil the manufacturers obligations as defined in MDR art
83, 84, 85 and 86.
• Post-market surveillance report (see MDR art 85)
- A Post Market Surveillance Report is required for class I devices (incl. classes Is, Im
and Ir) to summarize the results and conclusions of the data gathered as defined
in the PMS plan. The report includes the justification behind and the description of
preventive and corrective actions that have been taken, and it has to be updated
when necessary.
• Periodic Safety Update Report (PSUR) (see art 86)
- A PSUR is required for class IIa, class IIb and class III device, to summarize the results
and conclusions of the data gathered as defined in the PMS plan. The PSUR has to
include the conclusions of the benefit-risk determination, the main findings of the
post-market clinical follow-up, and the volume of sales of the device together with
information on the population using the device. The report includes the justification
behind and the description of preventive and corrective actions that have been taken.
• Post-market clinical follow-up (PMCF) (see MDR Annex XIV Part B)
- PMCF is part of PMS system.
- PMCF is the active collection of safety and performance data on clinical experience
when the device is use. For PMCF a wide range of scientific techniques can be used
to gather and analyze the clinical data, such as a registry study, a patient or physician

MDR Guide for Medical Device Software 69

 survey or a new clinical investigation.
• PMCF plan
- PMCF is undertaken in accordance with a PMCF plan. The PMCF plan should aim
to confirm safety and performance, identify unknown side-effects, identify contra-
indications or risks and ensure continued acceptability of the benefit-risk ratio.
- The PMCF plan has to describe the methods for data gathering and analysis in a
scientifically sound way. The objectives of the PMCF plan has to have acceptance
criteria.
- The PMCF is a continuous process that is post market part of clinical evaluation and
forms a bridge from evidence collected during the premarket stage with clinical data
collected when the device is in regular use.
• PMCF Report
- A Post Market Surveillance Report is not always required. However, a justification has
to be given in either the Clinical Evaluation Report, the PMCF plan or PMS plan.
- The following review criteria could use a justification that no additional clinical data is
needed:
› Where CE marking was based on equivalence, MDR art 61(10) or MDD / AIMDD
legacy device clinical data.
› High risk anatomical locations.
› High risk target populations e.g. pediatrics, elderly.
› Severity of disease/treatment challenges.
› Questions of ability to generalize clinical investigation results.
› Unanswered questions of long-term safety and performance.
› Results from any previous clinical investigation, including adverse events or from
post-market surveillance activities.
› Risks identified from the literature or other data sources for similar marketed
devices.
› Interaction with other medical products or treatments.
› Verification of safety and performance of device when exposed to a larger and
more varied population of clinical users.
› Emergence of new information on safety or performance.
› Identification of previously unstudied subpopulations which may show different
benefit/risk-ratio e.g. hip implants in different ethnic populations.
› Continued validation in cases of discrepancy between reasonable premarket
follow-up time scales and the expected life of the product.

6.7.2. Complaint Handling, Vigilance reporting and Market Surveillance

Feedback and complaint handling:

• ISO 13485 - 8.2.1 Feedback
• ISO 13485 - 8.2.2 Complaint handling

Vigilance reporting:
• MDR art 80 Recording and reporting of adverse events that occur during clinical
investigations
• MDR art 87 Reporting of serious incidents and field safety corrective actions
• MDR art 88 Trend reporting
• MDR art 89 Analysis of serious incidents and field safety corrective actions
• MDR annex III technical documentation on Post-Market Surveillance
• MEDDEV 2.12/1 Guidelines on a medical devices vigilance system & Additional
Guidance Regarding the Vigilance System as outlined in MEDDEV 2.12-1 rev. 8
• GHTF SG2 document N54 Appendix C : Global Guidance for Adverse Event Reporting
for Medical Devices provides useful guidance on the trending procedure.

Market surveillance:
• MDR art 90-100 Market Surveillance
• EU regulation 2019/1020 on market surveillance and compliance of products

MDR Guide for Medical Device Software 70

 Post Market Clinical
Clinical Evaluation Follow Up

(Claimed) benefits: Clinical evidence:

Positive impact on health? Sufficient?

Safety: No unacceptable Safety: New emerging risks

After the risks
device is placed on theormarket,
or side-effects? unknown the manufacturer and other economic operators
side-effects?
have the obligation to monitor the quality, performance and safety of a device throughout
(MDSW) Performance: Miasuse / off-label use:
its entireMeet
lifetime
intended (see paragraph
purpose? on PMS),
Correct report
intended incidents and correct those incidents.
purpose?
The essential part of to do this process is described in ISO 13485 – 8.2.1 Feedback (which
MDSW Clinical State of the Art:
includes Post Market
Association: Surveillance), ISO
Valid? 13485 – 8.2.2 Complaint handling and MDR
Changed?
art 87 Vigilance Reporting. In theory Manufacturers of class I products are exempt of
following the ISO 13485, however they are advised to implement this section of the ISO
13485.

The system has the following elements:

Figuur 33 6.7.2: Complaint Handling and Vigilance reporting
Figure 24 Complaint Handling and Vigilance reporting

MIR Form
MEDDEV 2.12

Field Safety Notice

MDR art 87

Field Safety Corrective

Complaint Reporting Action MDR art 87
Feedback Handling MDR art 87
ISO 13485-8.2.1 ISO 13485-8.2.2 MEDDEV 2.12
ISO 13485-8.2.3 Periodic Safety Report
MDR art 87
2 – 15 days
Adverse event reporting
MDR art 80

Trend Report
MDR art 88

The Complaint Handling and Vigilance reporting process can be setup in multiple ways.
Following are the typical elements in such a process:
• Feedback (see ISO 13485 - 8.2.1)
- The manufacturer has to setup a process to (actively) receive and review feedback.
There are two types of feedback:
› Event driven feedback: For example:
- A complaint report from a hospital that the MDSW was involved in the harm of a
patient.
- A service report that a bug did not allow the patient to be treated.
› Review driven feedback. The activities for review driven feedback are described in
the Post Market Surveillance Plan, for example:
- A helpdesk record review showing a trend in more customer calls after
the release of a software update, which qualifies as an alleged deficiency
(complaint). Often these reviews are part of a PMS report, PMCF report or
MDR Guide forClinical Evaluation
Medical Device Software Report. 14
- A development audit which uncovers a certain test has not been performed
correctly, which has to be reviewed if it can cause an alleged deficiency.
› The feedback has to be checked if it classifies as a complaint. If the feedback is an
alleged deficiency, it classifies as a complaint. See also the complaint definition in
ISO 13485: a written, electronic or oral communication that alleges deficiencies
related to the identity, quality, durability, reliability, usability, safety or performance
of a medical device that has been released from the organization’s control or
related to a service that affects the performance of such medical devices. Please
note that usability and service are included.
• Complaint handling (see ISO 13485 - 8.2.2)
- The complaints handling process has to follows the following typical steps:
› Document the complaint.
- Whether the device failed to meet specifications;
- Whether the device was being used for treatment or diagnosis; and
- The relationship, if any, of the device to the reported incident or adverse event.
- If the user has reported the complaint to the authorities, then ask for a copy of

MDR Guide for Medical Device Software 71

 the report.
› Investigate the complaint:
- The name of the device.
- The date the complaint was received.
- Any unique device identifier (UDI), and any other device identification(s) and
control number(s) used.
- The name, address, and phone number of the complainant.
- The nature and details of the complaint.
- The dates and results of the investigation.
- Any corrective action taken.
- Any reply to the complainant.
› Access the risk immediately (see MDR art 89) and check if the incident classifies as
a serious incident, since otherwise reporting timelines cannot be met.
› Justify if the complaint is not a serious incident and does not pose a safety or
performance risk and is therefore not reportable, for example:
- The MDSW is working as intended.
- The alleged deficiency is not a treatment or diagnostic feature.
- The alleged deficiency is 100% detectible prior to use.
- The alleged deficiency causes the device not to be usable.
- No product involved.
- The product stopped working safely.
› Verify if the risk analysis needs to be updated and if there are design changes
needed. For serious incidents a root cause investigation has to be performed if the
root cause is not yet known. (see MDR art 89 and ISO 14971).
› Describe corrections, preventive and corrective actions if required (see ISO 13485
– 8.5). This process is often called the CAPA process (Corrective Action and
Preventive Action). Create a CAPA if a Field Safety Notice (FSN) or Field Safety
Corrective Action (FSCA) is initiated. The CAPA also requires the effectiveness
check of the FSN and FSCA.
› Describe the handling of complaint-related product (see ISO 13485 – 8.3). This
includes products at the customer, stock in the warehouse and work in progress.
- The complaint handling process has to be compliant with the GDPR if patient data is
handled.
• Vigilance reporting (see MDR art 87):
- Vigilance reporting and its forms are described in MEDDEV 2.12/1, since this guidance
is based on the MDD / AIMDD, it is likely to be replaced in the coming years with
MDCG guidance. The MEDDEV 2.12 contains requirements to which Competent
Authority has to be reported until EUDAMED is ready. The Manufacturer Incident
Report form (MIR form) is used to report the serious incident according to MDR art
87 and Meddev 2.12. The Competent Authority in the Netherlands is IGJ. Based on
the reporting of the manufacturer the Competent Authority assesses the risk for the
public health and starts an investigation with follow-up actions as necessary.
- Any serious incident that occurs with a device that is not in the EEA, Turkey or
Switzerland and did not lead to a Field Safety Corrective Action is not reported
through vigilance in the EU.
- Incidents can be divided in two types:
› Serious incidents which need vigilance reporting.
› Non-serious incidents which need trend reporting.
- Serious incidents have to be reported within:
› 2 days for serious public health threats.
› 10 days in the event of death or an unanticipated serious deterioration in a
person's state of health
› 15 days for all other serious incidents.
- Field Safety Corrective Action (FSCA) and Field Safety Notice (FSN) (MDR art 87 and
89 and MEDDEV 2.12/1)
A Field Safety Corrective Action has to be reported immediately when identified in the
CAPA process to restore the safety and performance of the Medical Device. An FSCA
should be notified to the user via a Field Safety Notice.
- Product Summary Reports (PSR) (MDR art 87 (9) and MEDDEV 2.12/1)
- Product Summary Reports are used for reporting similar serious incidents when

MDR Guide for Medical Device Software 72

 agreed with the Competent Authority.
- S erious Adverse Events (SAE) (MDR art 80)
- Serious Adverse Events have to be reported in addition to vigilance reports if the
device is used in a Clinical Investigation.
• Trend Report (MDR art 88 and MEDDEV 2.12/1)
- Trend reports contain non-serious incidents that are normally received as complaints
that are not reported or expected side-effects. GHTF SG2 N54 Appendix C: provides
useful guidance on the setup of trend reporting.
- A trend report has to be submitted to the National Competent Authority (NCA) only
when any statistically significant increase in the frequency or severity of incidents
that are not serious incidents or that are expected to have undesirable side-effects
that could have a significant impact on the benefit-risk analysis.
- A trend report has to be submitted to the National Competent Authority (NCA)
according MDR art 88 where the manufacturer or its authorized representative has
his registered place of business.
• Periodic Safety Update Report (PSUR) (MDR art 86)
- The Periodic Safety Update Report has to be made for class IIa, IIb and III devices. The
PSUR summarizes analysis, results, CAPA’s and conclusions.
• Summary of Safety and Clinical Performance (SSCP) (MDR art 32)
- The Summary of Safety and Clinical Performance has to be made for class III and
implantable devices. The SSCP contains safety and performance information that
need to be clear for patients and users of the device.
• Market Surveillance (see MDR art 90 - 100):
- The competent authorities perform market surveillance activities to ensure that
medical devices meet the MDR requirements and do not endanger health and safety.
Market surveillance and control of products entering the EU market are described in
MDR art 90-100 and EU regulation 2019/1020. EUDAMED has a module for Market
Surveillance containing inspection reports of Economic Operators and yearly analysis
reports on the safety of the Medical Devices on the market. Based on those reports’
actions can be initiated to improve the situation by the competent authorities.
EUDAMED also gives the Competent Authorities quick access to other information
important for market surveillance, such as vigilance reporting and adverse event
reporting.

6.7.3. Maintenance, updates, upgrades, lifetimes and warrantees

• ISO 13485 - 7.5.4 Servicing activities

• •SO 13485 - 8.2.2 Complaint handling
• COCIR Good Maintenance Services Practice Guide: Optimising the equipment life
cycle

The MDR and the ISO 13485 do not give much clarity how to setup a program for
maintenance, updates, upgrades and lifetimes for MDSW. Although written for capital
equipment including software, the COCIR Good Maintenance Services Practice Guide
describe all the elements which are needed.

The maintenance program interferes with the complaint handling, where the question
arises, is corrective maintenance an alleged deficiency (see complaint definition ISO
13485) and should it therefore be handled as a complaint? When the manufacturer
handles corrective maintenance as complaints, several additional administrative
requirements arise, see ISO 13485 8.2.2 Complaint Handling. However, this might be
a safe approach, since many auditors are of the opinion that corrective maintenance
should be classified as complaints. When a manufacturer does not want to have this
administrative burden, then describing the conditions which might need maintenance,
like replacing a defective light bulb, should be described that these conditions are not
considered a complaint.

The Terms and Conditions of Sales should contain the conditions of a warrantee. A

MDR Guide for Medical Device Software 73

warrantee limits the liabilities of a manufacturer since it defines when the liabilities end.
The Instruction for Use should contain the lifetime of a device and the obligation for doing
updates and upgrades for a user, including commissioning, maintenance, training, service
contract, calibration, testing and other requirements linked to the safe use of a device.

6.7.4. Significant changes after placing the product on the market

• MDR art 83 (4) Preventive or corrective action, field safety corrective action.
• MDR art 120 (3) No significant changes to Legacy devices after Date of Application
• ANNEX VII Requirements to be met by Notified Bodies 4.9. Changes and
modifications
• ANNEX IX Conformity assessment based on a QMS and on assessment of technical
documentation 2.2c ”management of design or QMS changes”
• MDCG 2018-1 Guidance on basic UDI-DI and changes to UDI-DI
• MDCG 2020-3 Guidance on significant changes regarding the transitional provision
under MDR art 120 of the MDR with regard to devices covered by certificates
according to MDD or AIMDD
• NBOG 2014-3: Guidance for manufacturers and Notified Bodies on reporting of
Design Changes and Changes of the Quality System
• NB-MED/2.5.2/Rec2 Reporting of design changes and changes of the quality system

When the device is placed on the market, changes to the device often have a regulatory
impact:

• F or MDD/AIMDD no significant changes are allowed after 26 May 2021 if the device
remains on the market with a MDD/AIMDD certificate. Significant changes result in
MDR certification of that device. What a significant change is, is described in detail in
MDCG 2020-3. Design changes and changes in the intended purpose (called intended
use in the MDD and AIMDD) are considered significant. A significant change as result of
a corrective measure, can be implemented if accepted by the competent authority.
• For MDR devices the manufacturer shall have a procedure to manage design or QMS
changes see ANNEX IX. This procedure should be aligned with the agreement with the
Notified Body which defines (substantial) changes to be submitted to the Notified Body
for pre-approval see ANNEX VII 4.9. Other changes are reviewed during the Notified
Body audits.

Note the MDD/AIMDD and the MDR and its related guidance mix-up the terms for
significant and substantial change.

It is wise and required to review the consequences of the change before making it.
The MDCG 2020-3 guidance discusses several types of changes for MMM and AIMDD
products, which in general considered significant:

• Intended Purpose changes:

- Extension or change to the intended purpose.
- New user or patient population.
- Change of clinical use (example: anatomical site).
• Design or Performance Specification changes:
- Requires further clinical or usability data.
- New risks require control measures.
- Existing risks negatively affected.
- Change to built-in control mechanism.
- Change to operating principles, source of energy or alarms.
• Software changes:
- New or major change to operating system or component.
- New/modified architecture/database structure.
- Change of algorithm (but not software bug fixes, security updates).

MDR Guide for Medical Device Software 74

 - Required user input replaced by closed loop algorithm.
- New diagnostic or therapeutic features or new channel of interoperability.
- New user interface or presentation of data that impacts performance.
• QMS changes see MDCG 2020-3 9.6:
- Change in company ownership.
- Extension to manufacturing and/or design control.
- New facility or line modification/relocation.
- Significant modifications to special processes.
- Change in authority of the management representative.
- Post-market surveillance and vigilance issues.
- Concerns about implementation or corrective actions.

The Blue guide allows updates and repairs to software placed on the market, unless the
MDR describes more specific requirements. Note: an importer or distributor who changes
a Medical Device, becomes a Manufacturer, see the section about Economic Operators.

The following table discusses the impact of an update / change in such cases:

Table 17 Impact of changes

Change element Typical impact

Intended purpose change, for • Any change in intended purpose or indication is significant.
instance: This is also true for new claims impacting safety and
•N ew user or patient population performance of the device.
•C hange of clinical use (example: • Check risk class
new anatomical site) • New Basic-UDI-DI
• New UDI-DI
• MDR devices see ANNEX IX
• MDD / AIMDD device need MDR certificate after 26 May 2020
Significant and substantial • Significant changes include changes of the Basic UDI-DI.
design and QMS change / bug / • MDCG 2020-3 guidance discusses several types of
security update significant changes
• Check risk class
• New UDI-DI
• Class I check if this change has to be notified to the
Competent Authority
• Class IIa/IIb check if this change needs to be reviewed by the
Notified Body
• Class III check if a Technical documentation review by the
Notified Body is needed
Minor design change / bug / • Minor changes in general have no impact on the safety and
security update performance or essential security.
• New UDI-PI
Other changes • Any change to the data elements relating to the medical
device (e.g. trade name, product version, or model) may
require a new UDI-DI to be assigned.
• Any change which impacts the original performance, safety,
or the interpretation of data.
• A change to the name or trade name, version or model
number, critical warnings or contra-indications, user
interface language requires a new UDI-DI.

MDR Guide for Medical Device Software 75

07
MDR related costs

Chapter 7 describes the costs and resources needed to implement the MDR. In addition,
senior management commitment, a decent project plan, a dedicated project manager and
allocation of resources, are needed.

The following should be included in the MDR project plan:

• Where is the medical device going to be marketed?

• Which regulatory approvals are needed for those markets?
• Is reimbursement available in that market?
• For the MDR:
- Is the device a medical device according to the MDR (see qualification in chapter 3)?
- What is the product risk class (see classification in chapter 3)?
- What is the conformity assessment route (see chapter 4)?
- Is a suitable Notified Body available (see chapter 4)?
- What is needed for certification (see paragraph 2.2 and 4.4)?
- What is the intended purpose and what are the claims (see paragraph 3.2)?
- What is the (clinical) evidence needed for the intended purpose and the claims? Is that
evidence available or has that evidence to be created (see paragraph 5.6)?
- Are clinical investigations needed to create the evidence (see paragraph 5.6)?
• For the organization:
- Is suitable (external) expertise available (see table below)?
- Is a suitable PRRC available (see paragraph 6.3)?
- Is an Authorized Representative needed and available (see paragraph 6.4)?
- Are importers or distributors needed and available (see paragraph 6.4)?
- Are Appstore’s or cloud services foreseen, and do they meet regulatory requirements
(see paragraph 6.4)?
• Are there sufficient financial resources (see table below)?
• Is there a realistic timetable and can the medical device be ready in time (see table
below)?

The resource needs vary per medical device and risk classification. The following table
provides a rough estimation of these resources.

MDR Guide for Medical Device Software 76

Table 18 Estimation of resource needs

Activities Required Throughput time Cost Expert needed

Product related class I > 1 year > € 30k
out of pocket cost
class IIa/b € 250k - € 350k
class III > € 350k
• GSPR checklist class I - III > 2½ months > 160 hrs • MDR product external expert
class IIa/b & III > 160 hrs • Quality Manager
• Risk Management class I - III > 2½ months > 160 hrs • MDR product external expert
class IIa/b & III > 160 hrs • Quality Manager
class I > 160 hrs
class IIa/b > 1000 hrs
• Technical documentation class III > 1 year > 2200 hrs • MDR product external expert
class I > 160 hrs
class IIa/b > 1000 hrs • Quality Manager
class III > 2200 hrs
•C
 linical Evaluation during class IIa/b & III > 2½ months > 160 hours • Clinical evaluator
development • Physician reviewer
•C
 linical Evaluation class III > 2½ months > 160 hours • Clinical evaluator
pre-clinical investigation • Physician reviewer
•C
 linical Evaluation class I > 2½ months > 160 hours • Clinical evaluator
pre- market • Physician reviewer
• Product manual (and labels) class I - III > ½ year p.m. • Technical writing and label
designers
• Translations class I - III > 2 months Translation costs • Native speaking translators
calculate per word and reviewers with expertise in
over total of manual clinical application
words per language • Technical writing and label
designers
•C
 linical Investigation class III > ½ year Fees per country • CRO
approval (CCMO and Ethical (posted on the • Quality Assurance
committee) Competent Authority
website

• Clinical Investigation class III >> 1 year >> € 100k • CRO

• Investigators
• Quality Assurance

• QMS Manual setup class IIa/b & III 1 year € 25k • ISO 13485 consultant
(€ 80 – € 150 per
hour)

• QMS related class I - III 2 – 3-year total 5 - 10% of the time • Internal resources
MDR preparation of your internal
resources
• Product notification class I 1 month Fees see Competent • Quality Assurance
Authority website
• Product certification class IIa/b & III 1 year Fees as quoted per • Notified Body
(and Is / m / r) Notified Body • Quality Assurance
• QMS Certification class IIa/b & III (€ 250 – € 400 per • Notified Body
hour) • Quality Assurance
• Vigilance reporting class I - III Not applicable • Quality Assurance
• PMS and PMCF class I Not applicable > 160 hrs • PMS and PMCF not likely
class IIa/b > 320 hrs • PMS and possibly PMCF
class III >> € 100k • PMS and likely PMC

MDR Guide for Medical Device Software 77

Appendix 1: Resources and hyperlinks

Resource Topic URL / Search term

European Commission • Medical Devices overview page • ec.europa.eu/health/md_dialogue/overview_en
• MDR • Medical Device Regulation • ec.europa.eu/health/md_newregulations/overview_en
• MDCG guidance overview • ec.europa.eu/health/md_newregulations/guidance_en
• MDD • Guidance MEDDEVs • ec.europa.eu/health/md_sector/current_directives_en
• Consensus statements
• Informative documents
• Harmonized European standards

Competent Authorities • CAMD • www.camd-europe.eu

and Agencies in Europe • ENISA • www.enisa.europa.eu
Competent Authority • IGJ (Inspectie Gezondheidszorg • www.igj.nl
Netherlands en Jeugd) • www.rijksoverheid.nl/onderwerpen/medische-
• VWS (Volksgezondheid, Welzijn hulpmiddelen/nieuwe-wetgeving-medische-
en Sport) hulpmiddelen/meer-informatie-nieuwe-medische-
• CCMO (Centrale Commissie hulpmiddelen
Mensgebonden Onderzoek) • www.ccmo.nl
• RIVM (Rijksinstituut voor • www.rivm.nl
Volksgezondheid en Milieu) • www.cibg.nl
• CIBG (also known as Farmatec)
Competent Authority • FAGG (Federaal Agentschap • www.fagg.be/nl/MENSELIJK_gebruik/
Belgium voor Geneesmiddelen en gezondheidsproducten/medische_hulpmiddelen_
Gezondheidsproducten) hulpstukken
Competent Authority (US) • FDA • www.fda.gov
NANDO • Notified Bodies overview • ec.europa.eu/growth/tools-databases/nando/
Notified Body • Netherlands: BSI-NL, DEKRA & • www.bsigroup.com/nl-NL
DARE • www.dekra.nl
• www.dare.nl
• Belgium: SGS. • www.sgs.be
Notified Body guidance • Notified Body Operations Group • www.nbog.eu/nbog-documents/
• Team-NB documents • www.team-nb.org/team-nb-documents/
• NB-MED documents • www.team-nb.org/nb-med-documents/
Branch organizations for • COCIR (EU) • www.cocir.org
MDSW • Medtech Europe (EU) • www.medtecheurope.org
• FHI (NL) • www.fhi.nl
• FME (NL) • www.fme.nl
• OIZorg (NL) • www.oizorg.nl
• AGORIA (BE) • www.agoria.be
Competence centre • Nictiz (NL – data exchange) • www.nictiz.nl
• GEC Estro • www.estro.org
Standardization • ISO (International) • www.iso.org
• CEN-CENELEC(European) • www.cencenelec.eu
• NEN (NL) • www.nen.nl
• HL7 (NL) • www.hl7.nl
• DICOM • www.dicomstandard.org
• IEC • www.iec.ch
• HIMSS • www.himss.org
• UL • www.ul.com
• SNOMED CT • www.snomed.org
• WHO • www.who.org
• ANSI • www.ansi.org
Consultancy • Consultancy offices Netherlands • google search: medical device regulation consultant
or Belgium. Nederland / België
• Individual consultants are • google search: medical device regulation consultant
not easy to find. The RAPS België
NL meetings are visited by a
lot of consultants from the
Netherlands and Belgium.

MDR Guide for Medical Device Software 78

Resource Topic URL / Search term
Legal • Legal advice Netherlands or • google search: medical device regulation advocaat
Belgium Nederland
• Dutch language blogs about the • google search: medical device regulation advocaat België
MDR:
MDR blogs • Dutch language blogs about the • medicaldeviceslegal.com/
MDR • www.emergobyul.com/
UDI • GS1 • www.gs1.org
• HIBC • www.hibcc.org
• IFA • https://www.ifaffm.de/en/home
• ICCBBA • https://www.iccbba.org/

MDR Guide for Medical Device Software 79

Appendix 2: Terms, abbreviations and translations

English Term (abbreviation) Nederlandse term (afkorting) Remarks

Active Implantable Medical Device Richtlijn Actief Implanteerbare Definition see AIMDD
Directive (AIMDD) Medische Hulpmiddelen
American National Standards Institute
(ANSI)
Application Programming Interface (API)
Authorized Representative (AR) Gemachtigde Definition see MDR
Authorizations Dutch Government Bevoegdheden Nederlandse Overheid
Corrective Action and Preventive Action Correctieve en Preventieve Actie
(CAPA)
Competent Authority (CA) Bevoegde autoriteit
Competent Authorities for Medical Devices
(CAMD)
Clinical Investigation Klinisch Onderzoek Definition see MDR
CE Mark (European Conformity) CE Markering CE: Conformité Européenne,
Definition see MDR
Certificate of Free Sales Export verklaring
Code of Conduct Gedragsregels
Competent Authority (CA) Bevoegde Autoriteit Definition see MDR
Coordinating Competent Authority (CCA) Coördinerende Bevoegde Autoriteit
Central committee clinical investigation Centrale Commissie Mensgebonden
Onderzoek (CCMO)
Clinical Evaluation Consultation Procedure Raadplegingsprocedure voor de
(CECP) Klinische Evaluatie
Clinical evaluation report (CER) Rapport klinische evaluatie
Clinical investigation plan (CIP) Plan voor Klinisch Onderzoek
Coordinating Member State (CMS) Coördinerende Lidstaat
European Trade Association representing
the medical imaging, radiotherapy, health
ICT and electromedical industries (COCIR)
Contract Research Organization (CRO)
Custom-Made Devices Op maat gemaakte hulpmiddelen Definition see MDR
Declaration of Conformity (DoC) Conformiteitsverklaring Definition see MDR
Designating Authority (DA) Aanwijzende Autoriteit
Decree Medical Devices Besluit Medische Hulpmiddelen
Digital Imaging and Communications in
Medicine (DICOM)
Elektronische Gegevensuitwisseling in Gedragscode
de Zorg (EGIZ)
Electronic IFU (eIFU)
Essential Health and Safety Requirements Eisen aan Arbeidsomstandigheden
(EHSR) (ARBO)
European Standard (EN) Europese Norm (EN)
European Union Agency for Cybersecurity Europees agentschap voor
(ENISA) cyberbeveiliging
EUDAMED Actor Module (ACT) EUDAMED Participant Module

MDR Guide for Medical Device Software 80

English Term (abbreviation) Nederlandse term (afkorting) Remarks
EUDAMED Clinical Investigation / EUDAMED Klinisch Onderzoek /
Performance Studies Module (CIPS)
Prestatiestudies Module
EUDAMED Certificates / Notified Body EUDAMED Certificaten/Aangemelde
Module (CRF) Instantie Module
EUDAMED Data Exchange Module (DTX) EUDAMED Gegevens Uitwisseling
Module
EUDAMED Market Surveillance Module EUDAMED Markttoezicht Module
(MSU)
EUDAMED UDI / Device Module (UDID) EUDAMED Unieke Hulpmiddel-
Identificatie/Hulpmiddelen
EUDAMED Vigilance Module (VGL) EUDAMED Vigilantie Module
European Commission (EC) Europese Commissie
U.S. Food and Drug Administration (FDA) Autoriteit in de VS voor medische
hulpmiddelen
Fees and Fines Vergoedingen en boetes
Field Safety Corrective Action (FSCA) Corrigerende acties in verband met de
veiligheid in het veld
Field Safety Notice (FSN) Bericht inzake de veiligheid in het veld
Groupe Européen de Curiethérapie and
the European SocieTy for Radiotherapy &
Oncology (GEC ESTRO)
General Data Privacy Regulation (GDPR) Algemene Verordening
Gegevensbescherming (AVG)
Global Harmonisation Taskforce (GHTF)
Global Standards One (GS1) UDI issuing agency
Graphic User Interface (GUI) Grafische User Interface
General Safety and Performance Algemene Veiligheids- en Prestatie MDR Annex I
Requirements (GSPR) eisen
GS1 Global Trade Item Number (GTIN)
Health and Care Information models Zorg Informatie Bouwstenen
(HCIM)
Health Industry Bar Code (HIBC) UDI issuing agency
Health and Youth Care Inspectorate Inspectie Gezondheidszorg en Jeugd (IGJ)
Health Level Seven (HL-7)
Healthcare Information and Management
Systems Society, Inc. (HIMSS)
Health Products Regulatory Authority CA van Ierland
(HPRA)
Instructions for Use (IFU) Gebruiksaanwijzing Definition see MDR
International Atomic Energy Agency (IAEA) Internationaal Atoom Energie
Agentschap
Informationsstelle für Arzneispezialitäten UDI issuing agency
(IFA)
Implant card Implantaatkaart
International Electrotechnical Commission
(IEC)
In Vitro Diagnostics Regulation (IVDR) Europese Verordening over In-vitro Regulation (EU) 2017/746 on In Vitro
Medische Hulpmiddelen Diagnostic Medical Devices
Institute for Health and Environment Rijksinstituut voor Volksgezondheid en
Milieuhygiëne (RIVM)

MDR Guide for Medical Device Software 81

English Term (abbreviation) Nederlandse term (afkorting) Remarks
International Organization for
Standardization (ISO)
Language requirements Taaleisen
Dutch Implant Registry (LIR) Landelijk Implantaten Register (LIR)
Manufacturer and User Facility Device MAUDE houses medical device
Experience reports submitted to the FDA
(MAUDE) by mandatory reporters 1
(manufacturers, importers
and device user facilities) and
voluntary reporters such as health
care professionals, patients and
consumers.
Medical Device Coordination Group MDR art 103, 104, 105
(MDCG)
Medical Device Directive (MDD) Europese Richtlijn Medische
Hulpmiddelen
Medical Device (MEDDEV) Guidance
Medical Device Expert Group (MDEG) Previous name of MDCG
Medical Device Regulation (MDR) Europese Verordening over Medische Regulation (EU) 2017/745 on
Hulpmiddelen Medical Devices
Medical Device Reports (MDR, FDA)
Manufacturer Disclosure Statement on
Medical Device Security (MDS2)
Medical Device Single Audit Program
(MDSAP)
Medical Device Software (MDSW) Software voor Medische Hulpmiddelen Note: MDSW includes hardware,
SaMD is Stand-Alone Software.
Manufacturer Incident Report (MIR)

Member State (MS) Lidstaat

New Approach Notified and Designated Notified Body Database
Organizations (NANDO)
Nederlandse Federatie van Universitair
Medische Centra (NFU)
Dutch competence centre for electronic Nederlandse kennisorganisatie voor
exchange of health and care information digitale informatie-uitwisseling in de
(NICTIZ) zorg
Notification Notificatie of aanmelding
Notified Body (NB) Aangemelde Instantie
Notified Body Operational Group (NBOG) -
Post market clinical follow up (PMCF) Post-market Klinische follow-up
Post Market Surveillance (PMS) Toezicht na het in de handel brengen Definition see MDR
(post-market surveillance)
Periodic Summary Report on serious Periodieke samenvattende verslagen
incidents (PSR) over ernstige incidenten
Periodic Safety Update Report (PSUR) Periodiek veiligheidsverslag
Person Responsible for Regulatory Voor de naleving van de regelgeving MDR art 15
Compliance (PRRC) verantwoordelijke persoon
Patient Intervention Comparison Outcome PICO is een methode voor
(PICO) het beantwoorden van een
onderzoeksvraag
Product Summary Report (PSR)

MDR Guide for Medical Device Software 82

English Term (abbreviation) Nederlandse term (afkorting) Remarks
Quality Management System (QMS) Kwaliteitsmanagementsysteem
Registration, Evaluation, Authorization Regulation 1907/2006
and restriction of CHemicals (REACH)
Radio Equipment Directive (RED) Radioapparatuurrichtlijn
Restriction of Hazardous Substances Richtlijn Beperking gevaarlijke stoffen Richtlijn 2011/65/EU
(RoHS)
Rule Medical Devices (NL) Regeling Medische Hulpmiddelen (RMH)
Serious Adverse Event (SAE) Ernstige ongewenste voorvallen
Software as a Medical Device (SaMD) Software als Medisch Hulpmiddel Note: MDSW includes hardware,
SaMD is Stand-Alone Software.
EUROPEAN COMMISSION HEALTH & EC DG Gezondheid en voedselveiligheid Name no longer in use
FOOD SAFETY DIRECTORATE-GENERAL
(SANCO)
EUROPEAN COMMISSION HEALTH & EC DG Gezondheid en voedselveiligheid
FOOD SAFETY DIRECTORATE-GENERAL
(SANCO) EUROPEAN COMMISSION
HEALTH & FOOD SAFETY DIRECTORATE-
GENERAL (SANTE)
Secure Development Life Cycle (SDLC)
Serious Incident Report (SIR) Verslagen over ernstige incidenten
Single Identification Number for a CIPS Één identificatienummer voor een CIPS
(SIN)
Steering Group (SG) Stuurgroep
SNOMED CT medische standaard voor het
documenteren en coderen van
medische gegevens
System/Procedure Pack Producer (SPPP) Systeem /Procedure
verpakkingsproducent
Single Registration Number for an Uniek registratienummer voor
economic operator (SRN) marktdeelnemers
Summary of Safety and Clinical Samenvatting van veiligheids- en
Performance (SSCP) klinische prestaties
State of the Art Stand van de wetenschap Definition see MEDDEV 2.7/1 rev 4
Reprocessing of single use products Opwerking producten voor eenmalig
gebruik
Rules Medical Devices Regeling Medische Hulpmiddelen
Team NB (Notified Bodies) European association for Medical
Devices of Notified Bodies
Trend Report (TR) Trends rapport
Technical Report (TR) Technisch rapport As in CEN/TR 17223
Underwriters Laboratory (UL)
Unique Device Identification (UDI) Unieke hulpmiddelidentificatie MDR art 27
Unique Device Identification - Device Hulpmiddel identificatie Such as Part number
Identifier (UDI – DI)
Unique Device Identification – Production Productie Identificatie Such as Serial Number
Identifier (UDI – PI)
Ministry of Health, Welfare and Sports Ministerie van Volksgezondheid, Welzijn
en Sport (VWS)
Working Group (WG) Werkgroep
World Health Organization (WHO) Wereld Gezondheidsorganisatie

MDR Guide for Medical Device Software 83