Meeting an End-user Need in a Collaborative High Risk Medical
Device Software Development in Accordance with Future European
Stéphanie Py
, Thomas Lihoreau
, Marc Puyraveau
, Sylvain Grosdemouge
, Nadia Butterlin
Stéphanie Francois
, Morgane Eveilleau
, Aurélie Camelio
, Gérard Thiriez
, Floriane Ciceron
and Pauline Ecoffet
CHU Besançon, INSERM CIC 1431, Centre d'Investigation Clinique, Besançon, France
Shine Group, Châtillon-le-Duc, France
Univ. Bourgogne Franche-Comté, Institut Supérieur d'Ingénieurs de Franche-ComISIFC, Besançon, France
CHU Besançon, Department of Pediatric Intensive Care Unit, Besançon, France
Univ. Bourgogne Franche-Comté, Plateforme Centre de Simulation Universitaire en Santé CESIUS, Besançon, France
Keywords: High Risk Medical Device, Software, Pediatric Intensive Care, Clinical Investigation.
Abstract: Caring for a child in life-threatening distress is very stressful and error-prone for the caregivers. An end-user
need for a software that would free the child from human error and support the caregivers in the care of the
child has thus emerged. Free from the time-consuming and stressful constraints of calculating constants or
medication doses and consulting emergency protocols, caregivers could be more available and focused on the
vital care of the child. The extension of the scope of medical devices to software for medical purposes is one
of the important new points of the future European regulations. The very important overhaul of the previous
classification system with the addition of new rules or updating of old ones reinforces the regulations
applicable to software. The impact is considerable for the development and market access strategy of high-
risk classified software, and participate in a better security and efficacy of the marketed products, for better
healthcare. In this article we propose then to detail the strategy used for the development of a high-risk medical
device software intended to be used in pediatric intensive care units.
The term "medical device" (MD) as defined by the
European Medical Device Regulation (MDR)
2017/745 (EUR-lex, 2017a) may refer to an
instrument, apparatus, equipment or software
intended by its manufacturer to be used in humans.
Medical devices (MDs) are particularly difficult to
characterize because of their extreme diversity (pair
of glasses, hip prosthesis, dental implant…). This
variety is expressed through the very nature of the
MD, its complexity, its applications, its uses, its users
and the environment in which it is used. MDs may be
used for the diagnosis, prevention, control, treatment
and/or mitigation of disease or injury. To date, the
World Health Organization counts approximately
10,000 categories of MDs. In end and consequently
to these particularities, the evaluations of MDs need
to be adapted and relevant.
To ensure the health and safety of people, MDR
(updated and adopted in 2017 for an application in
next May 2021) specify the obligations to be
respected in their design, development, manufacture,
distribution... MD software is subject to the same
regulations as MD, however, the characteristics and
functionalities they provide often lead to additional
regulations. Indeed, it is necessary to ensure the
cybersecurity, to guarantee the protection of personal
data, sometimes to set up a user manual in electronic
format... In order to precisely determine the
applicable regulations, the process must be carried
out on a case-by-case basis, as each MD software has
its own characteristics and functionalities.
Unlike drugs, the regulations relating to MDs
(traceability, classification, marking) do not require a
Marketing Authorization. The placing on the market
of MDs is conditioned by obtaining the CE mark,
which is a stage in the development of the product.
Py, S., Lihoreau, T., Puyraveau, M., Grosdemouge, S., Butterlin, N., Francois, S., Eveilleau, M., Camelio, A., Thiriez, G., Ciceron, F. and Ecoffet, P.
Meeting an End-user Need in a Collaborative High Risk Medical Device Software Development in Accordance with Future European Regulations.
DOI: 10.5220/0010381502650273
In Proceedings of the 14th International Joint Conference on Biomedical Engineering Systems and Technologies (BIOSTEC 2021) - Volume 1: BIODEVICES, pages 265-273
ISBN: 978-989-758-490-9
2021 by SCITEPRESS Science and Technology Publications, Lda. All rights reserved
This unavoidable step requires sufficient proof of
safety and performance obtained through clinical
investigations for Class III and implantable devices.
The regulatory steps to perform interventional
clinical trials using high-risk MD software that don’t
get yet CE mark are cumbersome, time-consuming
and expensive. In order to collect quickly clinical data
and without requiring such steps, we have chosen to
conduct a first clinical investigation in two phases in
order to validate the use of a software calculating
doses and offering support algorithms in different
clinical situations of pediatric intensive care: a first
non-interventional one followed by a simulation.
2.1 Future European Regulations
The world of MDs within the European Union (EU)
is going through an important period in its history.
Technological advances, the need for harmonization
of practices within the EU and massively publicized
scandals such as the poly implant breast prosthesis
affair have led the various member states to reposition
themselves at the regulatory level. The European
Directive 93/42/EEC (EUR-lex, 1993) will give way
to the MDR 2017/745 common to all member states.
This new text aims to unify all MD players under a
single regulation, which is more comprehensive in the
current technological context. In particular, this new
regulation aims to improve traceability and
transparency at the European level, but also to be able
to monitor notified bodies more closely.
2.2 Specificities of High-risk MD
Not all MDs present the same level of risk in terms of
their use. The classification is based on the
destination of use and the potential risk of the MD for
the patient but also the healthcare staff and any other
person likely to use the device. The risk class of the
MD and the justification of the classification rules
shall be applied in accordance with Article 51 and
Annex VIII of the MDR 2017/745. This level of risk,
estimated by the application successively of 22 rules
and 80 criteria, makes it possible to identify 4 classes
for MDs, in order of criticality: I, IIa, IIb and III. The
classification rules are generally stricter in the
regulations than they were in the directives, which
will lead to a change of class for many MDs and some
will be classified as high-risk devices. The class is
very critical because it determines the applicable
requirements and the effort for a manufacturer is
incomparable between a Class I and a Class III.
In the same time and over the last few years, we
have seen an increased growth in the use of software
(on computers, mobile applications, embedded…) as
medical solutions (for diagnosis, monitoring,
measurements...) in the field of technologies for
health. Digital health technologies Software is digital
heath devices including artificial intelligence and
machine learning which has the vast potential to
improve the ability to accurately diagnose and treat
disease and to enhance the delivery of health care for
the individual. The new regulation has adapted to this
technological evolution and defines software and its
various classification rules. The definition of MD
clearly includes the software (section 2.1, chapter I of
the MDR 2017/745) and precise that software shall
also deemed to be an active device. MD software is
software that is intended to be used, alone or in
combination, for a purpose as specified in the
definition of a MD in the MDR. However, software
for general purposes, even when used in a healthcare
setting, or software intended for life-style and well-
being purposes are excluded from this definition. A
software controlling a device or acting on its use, i.e.
interacting with the device, is classified in the same
class as the device; a software independent of the
device is classified as such in application of point 3.3,
chapter II, Annex VIII of the MDR 2017/745. Rule
11 of Annex VIII was introduced into the MDR and
is intended to address the risks related to the
information provided by an active device. It describes
and categorizes the significance of the information
provided by the active device to the healthcare
decision (patient management) in combination with
the healthcare situation (patient condition). It states
that 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.
Performance and safety requirements specific to
software are presented in Annex I of the MDR
2017/745. It is specified that devices shall be
designed and manufactured in such a way as to
remove or reduce as far as possible the risks
associated with the possible negative interaction
between software and the IT environment within
which it operates and interacts (section 14.2 d) and in
accordance with the state of the art taking into
ClinMed 2021 - Special Session on Dealing with the Change in European Regulations for Medical Devices
account the principles of development life cycle, risk
management, including information security,
verification and validation. Software shall be
designed to ensure repeatability, reliability and
performance in line with their intended use (section
The evaluation of MD software is well supervised
in the new regulation. It requires the generation of
consistent documentation concerning the verification
and validation of the software. The design,
development process and validation must be
described. This information shall typically include the
summary results of all verification, validation and
testing performed both in-house and in a simulated or
actual user environment prior to final release (section
6.1, Annex II).
Software qualification, classification and clinical
evaluation are also based on guidance from for
example MDCG (Medical Device Coordination
Group; 2019-11 Guidance on qualification and
classification of Software in Regulation (EU)),
MEDDEV (2.1/6 Guidelines on the qualification and
classification of standalone software used in
healthcare within the regulatory framework for
medical devices), the manual on borderline and
classification in the community regulatory
framework for medical devices (July 2016, version
1.22 (05-2019) Court of Justice of the European
Union) and IMDRF (International Medical Device
Regulators Forum).
3.1 Context
Caring for a child in an emergency situation
according to the European Resuscitation Council
(ERC) guidelines (Maconochie et al., 2015) is very
stressful for caregivers who must provide quality care
as quickly as possible, while the prognosis is vital.
The severity of the child's condition is determined
after analysis of his vital signs (heart rate, blood
pressure, respiratory rate…), which depend on his
age. The doses of medication to be administered in
the emergency room are calculated according to the
child's weight. The knowledge of the norms of the
constants makes it possible to anticipate the child's
decompensation and to prevent cardiac arrest. The
latter is infrequent in pediatrics (10 to 15 times less
frequent than in adults) and generates extreme stress.
Care algorithms are available but the professionals of
pediatric intensive care units only use these on a very
punctual basis. Therefore, as soon as an exceptional
pathology occurs, they need to refer to the care
protocols in order to avoid any errors. Nevertheless,
rereading these protocols is time-consuming and this
loss of time is deleterious in the patient’s care.
The risk of medication errors by members of the
paramedical and medical team is high during patient’s
care due to the stressful nature of the situation, the
short period of time in which the calculations must be
performed, the lack of experience of some caregivers
and the diversity of the patient population (in terms of
age, weight and pathology). Medication errors are
made at different stages of patient care: when
estimating the child's weight, determining its
indication, consulting the recommended dose,
calculating, making the prescription, preparing and
administering it (Hoyle et al., 2012; Kaufmann et al.,
2012; Siebert et al., 2019).
The idea of developing a software tool to free
oneself from human error by ensuring the calculation
of constants and doses of emergency medication but
also to accompany the healthcare team in different
emergency situations emerged from a nurse of the
pediatric intensive care unit of the Besançon
University Hospital. The interest of the software tool
lies in the fact that it could provide better care for the
child and a better quality of life at work.
3.2 The Software Tool
The innovation of the software lies in the possibility
of having all the information necessary for pediatric
intensive care unit synthesized in an easy-to-use
software. The specifications were developed by
ISIFC students and the code by Shine Group. The
software has been built in full collaboration and
understanding of the caregiver’s practices and needs.
It is intended to be used on a tablet and is considered
as a stand-alone software. It offers 4 main functions:
- a calculation of the standards of physiological
constants and medication dosages used in the care
of an emergency situation based on the child's weight
and age. It also specifies the amount of energy to be
delivered with the defibrillator in the event of an
abnormal heart rhythm.
- assistance during resuscitation in emergency
situations such as cardiac arrest. The software
provides real-time details of the "defibrillatable" or
"non-defibrillatable" cardiac arrest care algorithm,
with the ability to switch between the two depending
on the situation. It indicates the treatment
administration times and informs the team leader of
the course of action to be taken. When a treatment
must be administered, a visual and audible signal
appears on the tablet. This way, the care team knows
Meeting an End-user Need in a Collaborative High Risk Medical Device Software Development in Accordance with Future European
how long the child has been in cardiac arrest, how
long resuscitation has been underway and at what
time the treatments were administered. This quick
access to the application requires neither reading nor
assimilation of the algorithm. The delays between
each step of the care are very precise. An integrated
stopwatch makes it possible to respect them.
- a guidance in the treatment procedures is
provided to the team during various emergency
situations. The size of the MDs to be used according
to the weight or age of the child or videos explaining
the gestures can also be consulted.
- a precise traceability is carried out as soon as a
medicine or a gesture is performed. All procedures
are listed in a care sheet that can then be printed and
integrated into the patient file.
This information is obtained in a reliable, quick
and simple way based only on the age and weight of
the child provided by the user. If the patient's weight
is not known, it will be calculated theoretically
according to the recommendations of the ERC. The
software has 7 tabs: vital constants, defibrillatable
cardiac arrest, non-defibrillatable cardiac arrest,
admission to emergency room, desaturation, supra-
ventricular tachycardia and actions (Figure 1). Inserts
at the top of the screen prompt to enter the patient's
age in months or years and weight if known. There is
also an insert with a stopwatch that starts
automatically at the beginning of a cardiac arrest care
but it is possible to start, stop and reset the stopwatch.
Buttons corresponding to the medical procedures
performed or medications administered are located at
the left of the screen.
Figure 1: Software homepage.
The information provided has been reduced to the
bare minimum so as not to overload the user with
information. All the recommendations indicated are
those issued by European learned societies such as the
ERC. Updates are possible and have already been
considered with Shine Group in order to adapt it to
the evolution of the ERC recommendations. The
language of the software may also need to be
modified to adapt to different computer media or
because of technological developments.
This software is an active MD allowing a
calculation of the values of theoretical physiological
constants according to patient’s age and weight. The
physician will then be able to make an integration and
request a quantity of medication to be administered.
According to the MDR 2017/745, this software is
intended to provide information which is used to
take decisions with diagnosis or therapeutic
purposes and may present an immediate danger to
the patient's life, such as resulting in death. It is
therefore classified as Class III. This class has been
determined using rule 11 of Chapter III of Annex VIII
of the MDR 2017/745.
Preliminary tests have been carried out with the
software using 50 fictitious patient age/weight
combinations in order to calculate constants and
dosages. Any deviation from the theory was
considered as an error. The software made no
calculation errors, while the caregivers made between
1 and 11. It takes less time than caregivers to perform
calculations (time saving up to 10 min and 29 s).
The proof of concept completed with this first
version of the software, the next step was to design a
clinical trial in order to acquire a first set of clinical
data that will:
- considerate real life data in order to comfort the need
and qualify/quantify the errors to avoid;
- allow upgrading the software that will be introduced
onto professional’s view.
This will participate in building the CE mark file.
3.3 Design of the Clinical Investigation
A regulatory manufacturer responsible for the long
and cumbersome procedure for obtaining the CE
mark has not yet been identified. As the ambition of
the project team is to quickly assess the interest of the
software in the care of the child in vital distress, a
pilot prospective, descriptive, comparative, and
monocentric study has been designed
The study entitled “Care of the child in vital
distress: evaluation of paramedical uses and benefits of
a software tool” comprises two phases, a first in real
situation then a second in simulation. It will allow to
obtain precise information on the errors encountered in
the care of pediatric emergencies. The impact of the
software on the reduction of errors in simulation, both
on dose calculations and on the care of cardiac arrest
will also be evaluated. It is planned to last 30-months
(in real conditions and in simulation).
ClinMed 2021 - Special Session on Dealing with the Change in European Regulations for Medical Devices
3.3.1 Phase 1: Non-interventional Study
This first part of the study will allow to describe
precisely the number and type of errors in real life
situations when treating a patient in vital distress aged
0 to 15 years old in the pediatric intensive care unit of
the Besançon University Hospital. Errors will be
classified according to their degree of seriousness, i.e.
whether or not they endanger the child. They will be
collected by a dedicated observer trained to identify
these errors, i.e. a caregiver in addition to the usual
team and who will not intervene in the care. Fifteen
patients will be included over a period of 1 year.
3.3.2 Phase 2: High-fidelity Simulation Tests
Simulation is an active and innovative pedagogical
method based on experiential learning and reflective
practice that allows to maintain theoretical and
practical skills but also to develop cohesion between
team members (Brock et al., 2013). The purpose of
health simulation is to recreate scenarios or technical
learning in a realistic environment with, as a double
objective, the immediate feedback of experience and
assessment of prior learning. These are clinical and/or
professional situations, simple or complex, usual or
exceptional, which are used as a support for the
construction of the scenarios. High-fidelity
simulation provides healthcare professionals with a
sophisticated mannequin that reproduces patient’s
physiological reactions to train how to react to critical
situations as close to reality as possible. This type of
simulation will be used in our study to evaluate the
effects of using our new software on the number and
type of care errors, non-technical skills, anxiety and
the feeling of self-efficacy of caregivers faced with a
scenario unfolding in a life-threatening emergency.
Ten expert teams of caregivers in caring for the
child in vital distress (intensive care units and
specialist mobile emergency units) and 10 non-expert
teams (pediatric medicine and pediatric emergencies)
will take part in the simulation tests over a period of
4 months. Each team will be composed of 3
caregivers (a senior physician and two paramedical
staff). The expert and non-expert caregivers will be
randomly assigned to one of the 10 expert and non-
expert teams. For each team, 2 simulation sessions
will be scheduled 2 months apart, one without the
help of the software and one with the help of the
software (order determined by drawing lots).
A software training session will precede the first
simulation session and then each session will be
divided into two distinct phases: the briefing will
specify the framework of the session and its
objectives and then the scenario development.
Scenarios will be built by physicians and paramedics
with extensive experience in simulation and not
taking part in the tests. During both sessions, teams
will be asked to care a cardiac arrest according to 2
scenarios of comparable difficulty but nevertheless
different in order to avoid their memorization. The
scenarios will be guided by the trainer who will adapt
their evolution according to the learner’s reactions.
Caregivers will be asked not to share the scenarios so
as not to bias the sessions for future caregivers. A
single debriefing will take place after the second
simulation session and will follow the PEARLS
(Promoting Excellence And Reflective Learning in
Simulation) framework to analyze the practices and
make a synthesis (Eppich & Cheng, 2015).
For each session, an external observer will collect
care errors and evaluate the effectiveness of
teamwork by determination of the TEAM (Team
Emergency Assessment Measure) score (Cooper et
al., 2010). After each session, an evaluation of the
anxiety and feeling of self-efficacy of caregivers will
be carried out using visual analog scales.
In order to initiate this clinical study, funding is
required. The clinical study protocol has been
submitted in September 2020 to the “APPARA”
(Appel à Projets PARAmédical) call proposed by the
interregional clinical research and innovation
grouping (GIRCI-Est, France) whose objective is to
support projects aimed at validating innovative
nursing or paramedical care methods. Funding has
been obtained and will allow this non-interventional
phase coupled with simulation tests to start in the first
months of 2021. It is a necessary preliminary step to
the design of a larger, controlled, randomized, multi-
center trial involving more patients and caregivers.
3.4 Usability and End-users
Usability is the degree to which a product can be used
by identified users, to achieve defined goals
effectively, efficiency and satisfaction, in a specified
context of use. This notion of usability is important to
consider in the healthcare field because non-usable
tools can waste time, lead to errors in use or even not
be used, which can create a risk for both patients and
professionals. In order to prevent these errors, the
MDR 2017/745 integrates this notion in the
demonstration of conformity, which includes
reference to harmonized standards with one dedicated
to the usability process (International
Electrotechnical Commission 62366:2015,
International Organization for Standardization or
Meeting an End-user Need in a Collaborative High Risk Medical Device Software Development in Accordance with Future European
ISO, 2015). The standard is based on two types user
interface evaluation:
- formative evaluation conducted throughout the user
interface design and development process. The aim is
to validate during development that the user interface
is usable in a correct way. This evaluation will
continuously feed the design input data, it is likely to
modify the user interface specification by revealing
new possible user errors, new dangerous situations…
- summative evaluation conducted after the device’s
design has been completed, it provides tangible
evidence of the safe use of the device.
Recently it has become far more explicit that
directly involving many different types of users, and
particularly end‐users, at all stages of MD technology
and assessment process is crucial. The position of
end-users in relation to devices allows them to better
judge the performance of the MD concerned, and thus
isolate problems encountered in its use. End-users
must be involved throughout the design cycle to
understand and specify the context in which the
device will be used, to specify user and organizational
requirements, to produce design solutions, and finally
to evaluate the solutions (Shah & Robinson, 2006).
The need for software to help calculate doses and
care cardiac arrest in pediatric intensive care units
came directly from an end-user, a nurse who regularly
encounters errors in the care of the child in vital
distress. A work was carried out upstream of the
software design to specify its conditions of use: the
medical indication (vital distress), the target patient
population (children of 0 to 15 years old), the
environment of use (emergency room), the user
profile (nurse or resident)... The identification of risks
related to use (possible errors of use, dangerous
situations…), was conducted following the
indications of the NF EN ISO 14971 standard (ISO,
2007), relating to the "application of risk management
to MDs". Several risks of different levels of
seriousness have been identified, such as a typing
error, a software failure or a bad calculation formula
following an update. This part was accomplished
thanks to the ISIFC regulatory and clinical assistance.
A formative evaluation of the software was
initiated during preliminary tests of calculations by
end-users. The scenarios proposed in the first clinical
investigation (described in paragraph 3.3.2) will
contribute to this type of evaluation. The ergonomics
and organization of the software may need to evolve
according to user feedback and in order to adapt to
different media: computer, tablet, laptop... Some
information in tabs or in the form of tabs may be
added or removed to best meet user expectations and
ERC recommendations. Similarly, calculation
formulas and support algorithms may be modified.
The aesthetics of the MD can also be reworked if
necessary. This type of evaluation will be pursued
throughout the development of the software in
particular through clinical trials. The summative
evaluation will be carried out on the final version of
the software.
4.1 Regulatory Approvals
Regulatory proceedings will be initiated in order to
start the study in the first months of 2021. This non-
interventional study corresponds to a research
involving human subjects with minimal risks and
constraints (category 3 according to the Jardé law
n°2012-300). Thus, a positive agreement from an
ethical committee is required to begin the study. The
study falls within the
scope of the MR003 reference
methodology and therefore will not require a request
for authorization from the Commission Nationale de
l'Informatique et des Libertés for the processing of
data from the research.
The study will be registered in the international
official web platform On a
product point of view, the software will need to be
presented to the French ANSM (Agence Nationale de
Sécurité des Médicaments et des produits de santé)
authority and formalized onto an investigator
brochure containing all the data available describing
the software and proving a strong level of
safety/efficacy in its technical claims.
4.2 Interventional Clinical Study
If the results of the pilot study are consistent with a
decrease in errors as a result of staff assistance with
the software, the value of the software in the care of
the child in vital distress will be assessed in a larger
study in real conditions care. Technical regulatory file
for assessing CE mark will need also to be strongly
constituted and advanced.
The study population will be expanded through
the participation of several hospital centers. The
patients themselves or the participating centers would
be randomly assigned to one of the two following
groups: an experimental group with software support
and a control group with routinely patient’s care in
the department. The main objective this time would
be to compare the number and type of errors
ClinMed 2021 - Special Session on Dealing with the Change in European Regulations for Medical Devices
committed with and without software. Some
secondary objectives of the pilot study, i.e. caregiver
anxiety and feeling of self-efficacy, could be assessed
under real-life care conditions. Other secondary
objectives would be added, such as the number of
deaths or objectives related to usability.
5.1 Development Stages of High-risk
MD Software
Bringing a high-risk medical device to market is a
highly regulated, complex and time-consuming
process, requiring numerous technical studies in order
to demonstrate the conformity of the device to
established safety standards by the European
Commission. Concerning our project, the stages
carried out and to come are described by the lifecycle
of our software presented in Figure 2.
Figure 2: Lifecycle of our software in accordance with the
MDR 2017/745 (UDI: Unique Device Identifier; PSUR:
Periodic Safety Update Report).
Before the market launch of a medical device, it is
imperative to define its family and its class according
to the regulations in force. The classification will
determine the regulatory requirements applicable to
ensure that all of those for placing on the market and
conformity assessment have been fulfilled. In our
case, the software is an active device of class III,
which imposes compliance with the strictest
regulatory requirements in terms of safety and
This step of design is followed by the clinical
evaluation composed of pre-clinical studies and
clinical investigations in the case of a high-risk
device. Our software is currently ready to start this
phase but regulatory approvals are still needed.
A complete technical documentation will then be
needed with the obligation to register an UDI (Unique
Device Identifier) which improve the security of
devices by a better traceability. The completion of the
assessments will be marked by the declaration of
conformity to the applicable regulatory requirements.
The market launch will be preceded by
registration of the software in the new Eudamed
European database always with a view to improving
traceability and transparency, but above all by
obtaining the CE mark. For high-risk MDs, the
intervention of a notified body chosen among those
appearing on the list of the European Commission
will be necessary to assess conformity of the device
according to the requirements of the MDR 2017/745
in order to obtain the CE mark.
Once the device is marketed, a surveillance
system will be set up to collect, record and analyze
data on the quality, performance and safety of the
device, during its entire life span. For our Class III
device, the manufacturer will draw up and annually
make available to the notified body a Periodic Safety
Update Report (PSUR), summarizing the results of
the analysis of the data from the post-market
surveillance system. It will aim to indicate that the
risk-benefit ratio is always positive in post-market.
This report must also be recorded in the Eudamed
platform. Post-market clinical studies may be
required to collect these performance and safety data.
5.2 Focus on Clinical Evaluation of
High-risk MD Software
Clinical evaluation is a systematic and planned
process to generate, collect, analyze and evaluate
clinical data on a device on an ongoing basis in order
to verify the safety and performance of the device,
including clinical benefits, when used as intended by
the manufacturer. This evidence complements the
pre-clinical evaluation data obtained through
laboratory testing and other verification and
validation results.
Different types of clinical evaluation are possible:
analyze data from the literature, compile data specific
to the device, use data from an already marketed
equivalent device, carry out a clinical investigation
involving the device to obtain unpublished data. The
use of equivalence is the simplest solution and is
reserved for non-innovative devices. Annex XIV (3)
of MDR specifies 3 characteristics that manufacturers
must consider when demonstrating equivalence:
technical (e.g. conditions of use, properties and
algorithms), biological (if applicable for software)
and clinical (e.g. clinical condition or purpose,
Meeting an End-user Need in a Collaborative High Risk Medical Device Software Development in Accordance with Future European
population and performance). Clinical investigation
of software rest on content validity (context of use
and concept of interest), construct validity, reliability
and sensitivity to change. It is the most difficult path
because it is long, risky and expensive. It is
nevertheless mandatory for all class III and
implantable MDs (Chapter VI, art 61 MDR),
including our software, except in special cases
introduced in the MDR 2017/745. For example,
equivalence can be applied if both manufacturers
have concluded an agreement allowing full and
permanent access to the technical documents
necessary to achieve equivalence, which may
severely limit the use of equivalence for clinical
evaluations. Equivalence can also be used within the
same group or the same manufacturer for range
Conformity assessments will require more
qualitative clinical evidence and data to demonstrate
the performance and safety of a device, the evaluation
of adverse side effects and the acceptability of the
benefit-risk ratio than ever before. Indeed, notified
bodies will be uncompromising in terms of the quality
and quantity of clinical data collected.
New documents will be requested for Class III
MDs including our software. The Summary of Safety
and Clinical Performance Characteristics (SSCP),
and the PSUR previously described in paragraph 5.1.
The SSCP is particularly useful to fight against the
lack of transparency since it will be published to the
public on the Eudamed platform. Moreover, the
clinical evaluation plan will be submitted to a
European expert group for decision upstream of the
clinical evaluation.
In conclusion, clinical evaluation is a continuous
process initiated for device certification and then
constantly updated with post-marketing surveillance.
We proposed to develop a MD software designed to
help paediatric drug preparation and care of cardiac
arrest during resuscitation with the aim to
significantly reduce the occurrence of medication
errors, anxiety and improve feeling of self-efficacy of
caregivers. Coupled with a feasibility and usability
study, the results of the pilot study will be used to
build a pivotal study that will demonstrate the real
interest of our software in the care of the child in vital
distress. It could have the potential to change
paediatric clinical practice in the area of emergency
However, many steps remain to be taken in order
to market a product that complies with the
regulations, but our work presented the interest of
building the evaluations in parallel to the product
development (technical, but also regulatory, business,
market point of view), each one feeding the other one.
The authors would like to thanks the students (Ida
Olsza, Antoine Giret, Clément Francioli, Léo
Martinet, Florian Zaouisand and Yaping Xu) for their
involvement in the project.
Brock, D., Abu-Rish, E., Chiu, C.-R., Hammer, D., Wilson,
S., Vorvick, L., Blondon, K., Schaad, D., Liner, D., &
Zierler, B. (2013). Interprofessional education in team
communication: Working together to improve patient
safety. Postgraduate Medical Journal, 89(1057),
Cooper, S., Cant, R., Porter, J., Sellick, K., Somers, G.,
Kinsman, L., & Nestel, D. (2010). Rating medical
emergency teamwork performance: Development of
the Team Emergency Assessment Measure (TEAM).
Resuscitation, 81(4), 446‑452.
Eppich, W., & Cheng, A. (2015). Promoting Excellence and
Reflective Learning in Simulation (PEARLS):
Development and rationale for a blended approach to
health care simulation debriefing. Simulation in
Healthcare: Journal of the Society for Simulation in
Healthcare, 10(2), 106‑115.
EUR-lex, 2017a. Regulation (EU) 2017/745 of the
European Parliament and of the Council of 5 April 2017
on medical devices.
EUR-lex, 1993. Council Directive 93/42/EEC of 14 June
1993 concerning medical devices, http://data.europa.
Hoyle, J. D., Davis, A. T., Putman, K. K., Trytko, J. A., &
Fales, W. D. (2012). Medication dosing errors in
pediatric patients treated by emergency medical
services. Prehospital Emergency Care: Official
Journal of the National Association of EMS Physicians
and the National Association of State EMS Directors,
16(1), 59‑66.
ISO, 2015. IEC 62366-1:2015
standard/63179.html (accessed 11.18.20).
ISO 14971: 2007
38193.html (accessed 11.18.20)
Kaufmann, J., Laschat, M., & Wappler, F. (2012).
Medication errors in pediatric emergencies: A
systematic analysis. Deutsches Arzteblatt International,
109(38), 609‑616.
ClinMed 2021 - Special Session on Dealing with the Change in European Regulations for Medical Devices
Legifrance, 2012. LOI n° 2012-300 du 5 mars 2012 relative
aux recherches impliquant la personne humaine
0901817L/jo/texte (accessed 11.18.20)
Maconochie, I. K., Bingham, R., Eich, C., López-Herce, J.,
Rodríguez-Núñez, A., Rajka, T., Van de Voorde, P.,
Zideman, D. A., Biarent, D., & Paediatric life support
section Collaborators. (2015). European Resuscitation
Council Guidelines for Resuscitation 2015: Section 6.
Paediatric life support. Resuscitation, 95, 223‑248.
Manual on borderline and classification in the community
regulatory framework for medical devices (July 2016,
version 1.22 (05-2019) Court of Justice of the European
MDCG 2019-11 Guidance on qualification and
classification of Software in Regulation (EU)
MEDDEV 2.1/6 Guidelines on the qualification and
classification of standalone software used in healthcare
within the regulatory framework for medical devices,
Shah, S. G. S., & Robinson, I. (2006). User involvement in
healthcare technology development and assessment :
Structured literature review. International Journal of
Health Care Quality Assurance Incorporating
Leadership in Health Services, 19(6‑7), 500‑515.
Siebert, J. N., Ehrler, F., Combescure, C., Lovis, C.,
Haddad, K., Hugon, F., Luterbacher, F., Lacroix, L.,
Gervaix, A., Manzano, S., & PedAMINES Trial Group.
(2019). A mobile device application to reduce
medication errors and time to drug delivery during
simulated paediatric cardiopulmonary resuscitation: A
multicentre, randomised, controlled, crossover trial.
The Lancet. Child & Adolescent Health, 3(5), 303‑311.
Meeting an End-user Need in a Collaborative High Risk Medical Device Software Development in Accordance with Future European