Meeting an End-user Need in a Collaborative High Risk Medical

Device Software Development in Accordance with Future European

Regulations

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-Comté ISIFC, 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.

1 INTRODUCTION

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

265

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 CONTEXT

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

Software

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

266

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

17.2).

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 THE CLINICAL NEED

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

Regulations

267

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

268

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

Regulations

269

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 NEXT CLINICAL VALIDATION

STEPS

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 ClinicalTrials.gov. 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

270

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 NEXT STEPS FOR BRINGING

THE FINAL SOFTWARE TO

MARKET

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

performance.

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

Regulations

271

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

upgrades.

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.

6 CONCLUSION

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

medicine.

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.

ACKNOWLEDGEMENTS

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.

REFERENCES

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),

642‑651.

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.

eu/eli/dir/1993/42/oj/eng.

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 https://www.iso.org/fr/

standard/63179.html (accessed 11.18.20).

ISO 14971: 2007 https://www.iso.org/fr/standard/

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

272

Legifrance, 2012. LOI n° 2012-300 du 5 mars 2012 relative

aux recherches impliquant la personne humaine

https://www.legifrance.gouv.fr/eli/loi/2012/3/5/SASX

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

Union)

https://ec.europa.eu/docsroom/documents/35582

MDCG 2019-11 Guidance on qualification and

classification of Software in Regulation (EU)

https://ec.europa.eu/docsroom/documents/37581

MEDDEV 2.1/6 Guidelines on the qualification and

classification of standalone software used in healthcare

within the regulatory framework for medical devices,

https://ec.europa.eu/docsroom/documents/17921/

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

Regulations

273