Mdcg 2019 11 guidance on qualification and classification of software mdr-ivdr

1
FINALLY PUBLISHED Guidance on Classification for Software
in MDR 2017/745 and IVDR 2017/746 MDCG 2019-11
Mistakes (and horrors) ☺
Antonio Bartolozzi
antonio.bartolozzi@bartolozzi.it 18/06/2019
State of
Healthcare
situation or
condition
Significance of information provided by SaMD to
healthcare decision
Treat or
diagnose
Drive clinical
management
Inform clinical
management
Critical III/IIb III/IIb III/IIb
Serious IIa IIa IIa
Non-serious IIa IIa IIa

2antonio.bartolozzi@bartolozzi.it
MDCG 2019-11 - Document
https://ec.europa.eu/docsroom/documents/37581?locale=en
Guidance on Classification for
Software in MDR 2017/745 and
IVDR 2017/746 MDCG 2019-11

WARNING – MDCG 2019-11
The document is not a European Commission document and it cannot
be regarded as reflecting the official position of the European
Commission. Any views expressed in this document are not legally
binding and only the Court of Justice of the European Union can give
binding interpretations of Union law

Software – MDCG 2019-11
For the purpose of this guidance,
“software” is defined as a set of
instructions that processes input
data and creates output data.
• It is not a standard definition
• The definition does not define a product !!!
• Classification and Qualification process is only for
products !!!!

Software - ISO/IEC/IEEE 26512:2018
3.22
software
all or part of the programs, procedures, rules, and associated documentation of
an information processing system
Note 1 to entry: For the purposes of this document, the term “software” does
not include on-screen documentation.
[SOURCE: IEEE Std 828-2012]
A product include documentation and labeling !

ISO 12207 : 2017 3.1.54 software product
3.1.54 software product
set of computer programs, procedures, and possibly
associated documentation and data
Note 1 to entry: A software product is a software system
viewed as the output (product) resulting from a process.

Software - ISO/IEC 2382:2015
software
<fundamental terms> all or part of the programs, procedures, rules, and associated
documentation of an information processing system
Note 1 to entry: Software is an intellectual creation that is independent of the medium
on which it is recorded.
Note 2 to entry: software: term and definition standardized by ISO/IEC [ISO/IEC
2382-1:1993].
Note 3 to entry: 01.01.08 (2382)
[SOURCE: ISO-IEC-2382-1 * 1993 * * * ]

MDSW – MDCG 2019-11
Medical Device Software (MDSW)
Medical device software is software that is intended to be used, alone or in
combination, for a purpose as specified in the definition of a “medical device”
in the medical devices regulation15 or in vitro diagnostic medical devices
regulation.16
This is not a product ! -> software is defined as
a set of instructions that processes input data
and creates output data SO it could be any part
of a computer program
• Do not define a product !
• I cannot apply the MDR to the MDSW!!!

3.12 MEDICAL DEVICE SOFTWARE EN 62304
software system that has been developed for the purpose of
being incorporated into the medical device being developed or
that is intended for use as a medical device
NOTE This includes a medical device software product, which
then is a medical device in its own right
• Same name !
• Different defintions !
• Overlapped purposes!
• This is a right defintion !
• it is appropriate only for the
purposes of the EN 62304 (not
for qualification and
classification purposes)
It is NOT a product
Product

ISO 12207 : 2017 3.1.55 software system
3.1.55
software system
system for which software is of primary importance to the stakeholders
Note 1 : In the most general case, a software system is comprised
of hardware, software, people, and manual procedures.
Note 2 : In a software system, software is the leading driver in meeting
system requirements.

Software as a Medical Device - IMDRF
SaMD is defined as software intended to be used for
one or more medical purposes that perform these
purposes without being part of a hardware medical
device.
http://www.imdrf.org/docs/imdrf/final/technical/imdrf-tech-
140918-samd-framework-risk-categorization-
141013.pdf#search=%22Framework%20for%20Risk%20Catego
rization%20and%20Corresponding%20%22
NOT software Embedded in hardware MD
SAMD IS A PRODUCT !
I can use this definition for qualification process
This is appropriate for a classifcation and qualification guideline!

Is there a Legal base for using IMDRF Guide (with MDR)?
(5) To the extent possible, guidance developed for medical devices at
international level, in particular in the context of the Global Harmonization
Task Force (GHTF) and its follow-up initiative, the International Medical
Devices Regulators Forum (IMDRF), should be taken into account to
promote the global convergence of regulations which contributes to a
high level of safety protection worldwide, and to facilitate trade, in
particular in the provisions on Unique Device Identification, general
safety and performance requirements, technical documentation,
classification rules, conformity assessment procedures and clinical
investigations
Legal base
We can use IMDRF definitions in a qualification and classification guideline !
… So why not use it ?

Qualification MDCG 2019-11
However, software which is intended to process, analyse, create or modify medical
information may be qualified as a medical device software if the creation or modification
of that information is governed by a medical intended purpose. For example, the software
which alters the representation of data for a medical purpose would qualify as a medical
device software.
You can qualify only products ! Are they talking about standalone software ?
Software can directly control a (hardware) medical device (e.g. radiotherapy
treatment software), can provide immediate decision-triggering information
(e.g. blood glucose meter software), or can provide support for healthcare
professionals (e.g. ECG interpretation software).
This software are part of the medical devices are not product ! And for sure
are not stand-alone software!

Decision steps for qualification of software as MDSW
There is no definition of a
product ‘Software’ in the
guideline.
Is this Software or product
‘software’ or software
included in the product ?
MDR Covers only
products !!!
Software and MDSW are not
products !!!
What about Rule 11 ?

MDR rule 3.3 of Annex VIII
Software, which drives a device or influences the use of a device, shall
fall within the same class as the device.
If the software is independent of any other device, it shall be classified in
its own right.
This means that a external software product that drives a
MD or influences a MD has the same class.
Software product that
drives a infusion pump
Software has the same
class of the infusion
pump

MDR rule 3.5 of Annex VIII
3.5. If several rules, or if, within the same rule, several
sub-rules, apply to the same device based on the device's
intended purpose, the strictest rule and sub-rule resulting
in the higher classification shall apply.

MDR rule 3.5 - Example - MDCG 2019-11
Melanoma image analysis software intended to be used with a near-infrared laser light
scanner, which is considered class IIa per Rule 10. The software “drives or
influences the use of” the near- infrared laser light scanner as it is intended to take
control of the scanner by letting it execute proprietary multi-exposure programs for
the detection of melanoma. As such, implementing rule 3.3 applies. However, Rule
11 would also apply based on the intended medical purpose of the software
e.g. cancer diagnosis. The MDSW would be classified as class III based on Rule 11
(see section Classification Rules) and per implementing rule 3.5 of Annex VIII.
Is there a unacceptable RISK - of death or an
irreversible deterioration of a person's state of health
- after consideration of RISK CONTROL measures
external to the SOFTWARE SYSTEM?
NO
There are a number of RISK
CONTROL measures before a
death or an irreversible
deterioration of a person's state
of health (e.g. patient visit by
the physician).
Is there a unacceptable RISK - of a serious
deterioration of a person's state of health - after
consideration of RISK CONTROL measures external to
the SOFTWARE SYSTEM?
YES Class IIb

c.1.) Electronic Patient Record Systems (EPR)- MDCG 2019-11
Electronic patient record systems are intended to store and transfer electronic patient
records. They archive all kinds of documents and data related to a specific patient. The
electronic patient records should not be qualified as a medical device, i.e. an electronic
patient record that simply replaces a patient’s paper file does not meet the definition of
a medical device.
What about Rule 11 ?
Sub-rule 11a), states that MDSW (which is intended to provide information which is
used to take decisions with diagnosis or therapeutic purposes) is classified as class IIa.
(Pag 13 4.2 Classification Rules MDCG 2019-11)
EPR are intended to provide information which is used to take decisions
with diagnosis or therapeutic purposes! E.g. Vital parameters (SpO2,
NIBP, IBP, HR, etc.) are stored and shown by EPR
CLASS IIa

c.1.1.) CIS / Patient Data Management Systems – PDMS – MDCG 2019-11
A CIS/PDMS is a software-based system primarily intended to store and transfer
patient information generated in association with the patient’s intensive care
treatment (e.g. intensive care units).
Usually the system contains information such as patient identification, vital
intensive care parameters and other documented clinical observations.
These CIS/PDMS are not qualified as medical devices.
PDMS intended use is to
automatically document vital
parameters sampled by monitors
and to replace handwritten medical
files for clinical use.
Clinical Benefits of PDMS* Yes(%) No(%) Undecided(%)
PDMS helps save time 68 10 22
PDMS faciliates compliance
with standards of therapy
66 16 18
PDMS supports therapy-
planning
42 12 46
PDMS faciliates therapeutic
decision
34 14 52
*Patient Data Management Systems in Critical Care
REINHOLD FRETSCHNER, WOLFGANG
BLEICHER, ALEXANDRA HEININGER, and
KLAUS UNERTL
Klinik für Anaesthesiologie der Universität
Tübingen, Tübingen, Germany
PDMS are intended to
provide information which is
used to take decisions with
diagnosis or therapeutic
purposes!
Class IIa
What about rule 11?

Rule 11 – subrule b)
Software intended to monitor physiological processes is classified as class IIa,
except if it is intended for monitoring of vital physiological parameters, where
the nature of variations of those parameters is such that it could result in
immediate danger to the patient, in which case it is classified as class IIb.

Sub-rule 11 b) - MDCG 2019-11
Sub-rule 11b) was introduced to ensure that MDSW which has the same
intended purpose as (hardware) devices which would fall under rule 10, third
indent, are in the same risk class.
However, this sub rule applies to MDSW intended to be used for monitoring
any/all physiological processes and not just vital physiological processes
(equivalent to rule 10, third indent ).
Vital physiological processes and parameters include, for example, respiration,
heart rate, cerebral functions, blood gases, blood pressure and body
temperature.
the same intended use implented in a pure hardware MD, and in a pure software
MD have two different classifications.
monitoring NON vital
physiological processes
Hardware MD Class I
Software MD Class IIa/IIb
Is a Art 51 violation?

MDR Art. 51
Art.51: Devices shall be divided into classes I,
IIa, IIb and III, taking into account the intended
purpose of the devices and their inherent risk.
<omissis>
Devices cannot be divided into classes,
taking into account the «device design and
construction methods»
Is Rule 11 complaint with Art. 51?

Medical Device Software (MDSW) MDCG 2019-11
Medical device software (MDSW) is a term used throughout
this document and shall be meant as all software that is
intended to be used, alone or in combination, for a medical
purpose specified in the definition of a “medical device” in
the MDR or IVDR, regardless of whether the software is
independent or is driving or influencing the use of a
device.
MDCG 2019-11 MDSW <> SaMD

What about Rule 11 and Art. 51?
SaMD standalone is for sure more dangerous than MD
hardware and MD firmware. SaMD (standalone) is
running into not strictly controlled environment (low
controls for operating systems, hardware, other running
software /SOUP, antivirus).
If (Software = SaMD ) then
Software in Rule 11 complies with Art. 51.

Reductio ad absurdum. Rule 11 vs art. 51
absurdum
Software embedded (i.e. firmware) is more dangerous than hardware
Software embedded (i.e. firmware) is safe as hardware. Really, there is
no difference at all between hardware and firmware: some CPUs has
microcode (=firmware) that runs inside processors. Firmware is running
in a strictly controlled environment.
There is no reason that software embedded part of hardware MD, is
more dangerous than «pure» hardware device.
Devices cannot be divided into classes, taking
into account the device design and construction
methods
Devices shall be divided into classes I, IIa, IIb and III,
taking into account the intended purpose of the devices
and their inherent risk
If (Software = MD firmware ) then
Rule 11 Software = SaMD

Usability of the IMDRF risk classification framework in the context
of the MDR - MDCG 2019-11
Significance of Information provided by the
MDSW to a healthcare situation related to
diagnosis/therapy
StateofHealthcare
situationorcondition High
Treat or
diagnose
~ IMDRF 5.1.1
Medium
Drives clinical
management
~ IMDRF 5.1.2
Low
Informs clinical
management
(everything
else)
Critical
situation or
condition
~ IMDRF 5.2.1
Class III
Type IV.i
Class IIb
Type III.i
Class IIa
Type II.i
Serious
situation or
condition
~ IMDRF 5.2.2
Class IIb
Type III.ii
Class IIa
Type II.ii
Class IIa
Type I.ii
Non-serious
situation or
condition
(everything
else)
Class IIa
Type II.iii
Class IIa
Type I.iii
Class IIa
Type I.i
The IMDRF codes are inverted from what defined in IMDRF document!!!!!!

Factors Important for SaMD characterization
The intended use of the information provided by SaMD in clinical
management has different significance on the action taken by the
user:
1. Treat or diagnose
2. Drive clinical management
3. Inform clinical management

To treat or to diagnose
Treating and diagnosing infers that the information provided by the SaMD
will be used to take an immediate or near term action:
• To treat/prevent or mitigate by connecting to other medical devices,
medicinal products, general purpose actuators or other means of
providing therapy to a human body
• To diagnose/screen/detect a disease or condition (i.e., using sensors,
data, or other information from other hardware or software devices,
pertaining to a disease or condition).
We can take (immediate) decisions with diagnosis or therapeutic purposes

To drive clinical management
Driving clinical management infers that the information provided by the SaMD
will be used to aid in treatment, aid in diagnoses, to triage or identify early
signs of a disease or condition will be used to guide next diagnostics or next
treatment interventions:
• To aid in treatment by providing enhanced support to safe and effective
use of medicinal products or a medical device.
• To aid in diagnosis by analyzing relevant information to help predict risk of
a disease or condition or as an aid to making a definitive diagnosis.
• To triage or identify early signs of a disease or conditions.
We can (aid to) take decisions with diagnosis or therapeutic purposes

To Inform clinical management
Informing clinical management infers that the information provided by the
SaMD will not trigger an immediate or near term action:
• To inform of options for treating, diagnosing, preventing, or mitigating a
disease or condition.
• To provide clinical information by aggregating relevant information (e.g.,
disease, condition, drugs, medical devices, population, etc.)
We can take decisions (non-immediate) with diagnosis or therapeutic purposes

Factors Important for SaMD characterization
The intended use of the information provided by SaMD in clinical
management has different significance on the action taken by the
user:
1. Treat or diagnose
2. Drive clinical management
3. Inform clinical management
1. ...Immediate..
2. …To Aid…
3. ..Non-immediate...
decisions with
diagnosis or
therapeutic
purposes

IMDRF SaMD Categories
State of
Healthcare
situation or
condition
healthcare decision
Treat or
diagnose
Drive clinical
management
Inform clinical
management
Critical IV III II
Serious III II I
Non-serious II I I

IMDRF SaMD Categories
State of
Healthcare
situation or
condition
healthcare decision
diagnosis or therapeutic purposes always involved
Treat or
diagnose
Immediate
Drive clinical
management
aid
Inform clinical
management
Non-immediate
Critical IV III II
Serious III II I
Non-serious II I I

Considerandum 58 (serious adverse event)
“serious adverse event” means any adverse event that led to any of the following:
a) death,
b) serious deterioration in the health of the subject, that resulted in any of
the following:
i. life-threatening illness or injury,
ii. permanent impairment of a body structure or a body function,
iii. hospitalisation or prolongation of patient hospitalisation,
iv. medical or surgical intervention to prevent life-threatening illness
or injury or permanent impairment to a body structure or a body
function,
v. chronic disease,
c) foetal distress, foetal death or a congenital physical or mental impairment or
birth defect;

IMDRF Critical vs MDR Serious
IFMDR Guide (Critical condition) MDR Serious «condition»
Situations or conditions where accurate and/or timely diagnosis or
treatment action is vital to avoid death, long-term disability or other
serious deterioration of health of an individual patient or to mitigating
impact to public health. SaMD is considered to be used in a critical
situation or condition where:
• The type of disease or condition is:
o Life-threatening state of health, including
incurable states,
o Requires major therapeutic interventions,
o Sometimes time critical, depending on the
progression of the disease or condition that could
affect the user’s ability to reflect on the output
information.
• Intended target population is fragile with respect to the
disease or condition (e.g.,pediatrics, high risk population,
etc.)
• Intended for specialized trained users.
a) serious deterioration in the health of the subject, that
resulted in any of the following:
i. life-threatening illness or injury,
ii. permanent impairment of a body structure or a body
function,
iii. hospitalisation or prolongation of patient hospitalisation,
iv. medical or surgical intervention to prevent life-
threatening illness or injury or permanent
impairment to a body structure or a body function,
v. chronic disease,
MDR Rule 11 : a serious deterioration of a
person's state of health or a surgical
intervention (IIb)
MDR Rule 11 : death or an
irreversible deterioration of a
person's state of health (III)
WARNING: A life-threatening disease is a very serious one that can cause death!

MDR inconsistency
life-threatening disease (➔may cause death) and an
irreversible deterioration of a person's state of health
seems included in a serious deterioration in the health
of the subject (see Considerandum 58)
Software intended to provide information which is used to take decisions
with diagnosis or therapeutic purposes is classified as class IIa, except if
such decisions have an impact that may cause:
• death or an irreversible deterioration of a person's state of health,
in which case it is in class III; or
• a serious deterioration of a person's state of health or a surgical
intervention, in which case it is classified as class IIb.
Software intended to monitor physiological processes is classified as class
IIa, except if it is intended for monitoring of vital physiological parameters,
where the nature of variations of those parameters is such that it could
result in immediate danger to the patient, in which case it is classified as
class IIb.
All other software is classified as class I
!?

Serious situation or condition (IMDRF)
Situations or conditions where accurate diagnosis or treatment is of vital importance to avoid
unnecessary interventions (e.g., biopsy) or timely interventions are important to mitigate long term
irreversible consequences on an individual patient’s health condition or public health.
SaMD is considered to be used in a serious situation or condition when:
• The type of disease or condition is:
o Moderate in progression, often curable,
o Does not require major therapeutic interventions,
o Intervention is normally not expected to be time critical in order to avoid death, longterm
disability or other serious deterioration of health, whereby providing the user an ability to detect
erroneous recommendations.
• Intended target population is NOT fragile with respect to the disease or condition.
• Intended for either specialized trained users or lay users.
Note: SaMD intended to be used by lay users in a "serious situation or condition" as described here,
without the support from specialized professionals, should be considered as SaMD used in a "critical
situation or condition".
Seriuous condition (IMDRF guide) Non-Serious condition (MDR)

MDR Classification using IMDRF guide
State of
Healthcare
situation or
condition
(IMDRF)
healthcare decision (always
Treat or
diagnose
Drive clinical
management
Inform clinical
management
Critical IIb IIb IIb
Serious IIa IIa IIa
Non-serious IIa IIa IIa
Non-serious MDR
serious MDR

Better one ☺
Significance of Information provided by the
MDSW to a healthcare situation related to
diagnosis/therapy
StateofHealthcare
situationorcondition High
Treat or
diagnose
~ IMDRF 5.1.1
Medium
Drives clinical
management
~ IMDRF 5.1.2
Low
Informs clinical
management
(everything
else)
Critical
situation or
condition
~ IMDRF 5.2.1
Class III/IIb
Type IV.i
Class III/IIb
Type III.ii
Class III/IIb
Type II.iii
Serious
situation or
condition
~ IMDRF 5.2.2
Class IIa
Type III.i
Class IIa
Type II.ii
Class IIa
Type I.ii
Non-serious
diagnostic or
therapeutic
actions
Class IIa
Type II.i
Class IIa
Type I.i
Class IIa
Type I.iii

Example II.i – MDCG 2019-11 (pag. 27)
MDSW intended to rank therapeutic suggestions for a health care professional
based on patient history, imaging test results, and patient characteristics, for
example, MDSW that lists and ranks all available chemotherapy options for
BRCA-positive individuals, should be classified as class IIa per Rule 11(a)
‾ IMDRF Risk Category II.i as it informs clinical management for cancer, a
critical disease.
State of
Healthcare
situation or
condition
Significance of information provided by
SaMD to
healthcare decision
Treat or
diagnose
Immediate
Drive clinical
management
aid
Inform
clinical
management
Non-
immediate
Critical IV III II
Serious III II I
Non-serious II I I
II.iii SaMD that provides information to
inform clinical management for a
disease or conditions in a critical
situation or condition is a Category II
and is considered to be of
medium impact.
Class IIb/III

Type II.iii IMDRF ➔ III/IIb MDR
Software intended to provide information
which is used to take decisions with
diagnosis or therapeutic purposes
<when> such decisions have an impact that
may cause:
• death or an irreversible deterioration of
a person's state of health, in which case
it is in class III (?)
• a serious deterioration of a person's
state of health or a surgical intervention,
in which case it is classified as class IIb
Significance of
Information
provided by the
MDSW to a
healthcare
situation related
to diagnosis/
therapy
StateofHealthcare
situationor
condition
Low
Informs clinical
management
(everything else)
Critical
situation or
condition
~ IMDRF 5.2.1
Class IIa
Class III(?)/IIb
Type II.iii
Software can cause a (non immediate)
critical condition (a serious deterioration
of a person's state of health or a surgical
intervention, life-threatening illness or
injury included )
III(?)/IIb
critical
condition
It is not «II.i» !

Conclusions
• IMDRF definitions do not map the MDR
definitions
• Does the MDSW definition comply with MDR
Rule 11 and Art. 51?
• There is a lot of mistakes
• Some Examples and the flow chart are nearly
the same in MDCG2019-11 as in the old
MEDDEV 2.1/6 (it seams do not take into
account the new rule 11)
This guideline is not legally binding,
but … please justify any deviation
Stay tunned for video lesson! ☺

Mdcg 2019 11 guidance on qualification and classification of software mdr-ivdr

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to Mdcg 2019 11 guidance on qualification and classification of software mdr-ivdr

Similar to Mdcg 2019 11 guidance on qualification and classification of software mdr-ivdr (20)

More from Antonio Bartolozzi

More from Antonio Bartolozzi (10)

Recently uploaded

Recently uploaded (20)

Mdcg 2019 11 guidance on qualification and classification of software mdr-ivdr