Auteure

Contact

• Chris­ti­na Roxanne GBELAY : cgbelay@laposte.net

Citation

A rap­pe­ler pour tout usage : Chris­ti­na Roxanne GBELAY, « Mise en place d'un sys­tème de mana­ge­ment de la qua­li­té selon l'ISO 13485v2016 : Zoom sur la Vali­da­tion des Appli­ca­tions Logi­cielles », Uni­ver­si­té de Tech­no­lo­gie de Com­piègne (France), Mas­ter Ingé­nie­rie de la San­té, Mémoire de Stage, https://travaux.master.utc.fr/, réf n° IDS147, sep­tembre 2022, https://travaux.master.utc.fr/formations-master/ingenierie-de-la-sante/ids147/

Résumé

Le 26 mai 2021 marque un tour­nant pour les pro­fes­sion­nels tra­vaillant dans le sec­teur des dis­po­si­tifs médi­caux. En effet, cette date cor­res­pond à l’entrée en appli­ca­tion de la nou­velle régle­men­ta­tion autour des Dis­po­si­tifs Médi­caux (DM) et des Dis­po­si­tifs Médi­caux de Diag­nos­tic In Vitro (DMDIV) : Les règle­ments 2017/745 et 2017/746.

Cette nou­velle règle­men­ta­tion, visant à har­mo­ni­ser et à ren­for­cer les pra­tiques de com­mer­cia­li­sa­tion des dis­po­si­tifs médi­caux sur le mar­ché euro­péen, apporte avec elle de nou­velles dis­po­si­tions, pour assu­rer la qua­li­té, la sécu­ri­té et la per­for­mance des dis­po­si­tifs médi­caux [1].

Par­mi ces dis­po­si­tions, la mise en place d’un Sys­tème de ges­tion de la qua­li­té ren­for­cé, pour les indus­triels du dis­po­si­tif médi­cal, devient une exi­gence indispensable.

Pour cette mise en place une norme har­mo­ni­sée spé­ci­fique aux indus­triels du DM existe : L’ISO 13485 : 2016.

La vali­da­tion des appli­ca­tions logi­cielles est une exi­gence de cette norme tou­chant de près les indus­triels du DM. Cette exi­gence repré­sente encore aujourd’hui, près de 6 ans après son appa­ri­tion, une source impor­tante de non-confor­mi­té, lors des audits de cer­ti­fi­ca­tion ISO 13485 : 2016. Cette exi­gence est cepen­dant incon­tour­nable pour la majo­ri­té des entre­prises de dis­po­si­tifs médi­caux, car il est très rare à l’heure actuelle, de trou­ver une entre­prise qui n’utilise pas de logi­ciel dans le sou­tien de ses acti­vi­tés [2].

Mots-clés : Dis­po­si­tif médi­cal - Sys­tème de Mana­ge­ment de la qua­li­té - Vali­da­tion des appli­ca­tions Logi­cielles du SMQ - ISO 13485

Abstract

May 26, 2021 marks a tur­ning point for pro­fes­sio­nals wor­king in the medi­cal device sec­tor. Indeed, this date cor­res­ponds to the entry into appli­ca­tion of the new regu­la­tion around Medi­cal Devices (DM): Regu­la­tion 2017/745 (MDR).

This new regu­la­tion, aimed at har­mo­ni­zing and streng­the­ning mar­ke­ting prac­tices for medi­cal devices on the Euro­pean mar­ket, brings with it new pro­vi­sions to ensure the qua­li­ty, safe­ty, and per­for­mance of medi­cal devices [1].

Among these pro­vi­sions, the imple­men­ta­tion of a rein­for­ced Qua­li­ty Mana­ge­ment Sys­tem for medi­cal device manu­fac­tu­rers is beco­ming an essen­tial requi­re­ment. For this imple­men­ta­tion, a har­mo­ni­zed stan­dard spe­ci­fic to medi­cal devices indus­trials exists : ISO 13485 : 2016.

The vali­da­tion of soft­ware for medi­cal devices qua­li­ty sys­tem is a requi­re­ment of this stan­dard that clo­se­ly affects medi­cal devices indus­trials. This requi­re­ment remains today, almost 6 years after its appea­rance, a major source of non-com­pliance during ISO 13485 : 2016 cer­ti­fi­ca­tion audits. This requi­re­ment is howe­ver una­voi­dable for most medi­cal device com­pa­nies, because it is very rare at present, to find a com­pa­ny that does not use soft­ware in sup­port of its acti­vi­ties [2].

Key­words : Medi­cal Device – Qua­li­ty Mana­ge­ment sys­tem - Vali­da­tion of soft­ware for QMS - ISO 13485

Téléchargements

Remerciements

Je tiens tout pre­miè­re­ment à remer­cier l’ensemble de l’équipe péda­go­gique du mas­ter IDS, qui nous a déli­vré des ensei­gne­ments de qua­li­té, et qui nous a mis en inter­ac­tion avec de nom­breux pro­fes­sion­nels de notre domaine.

Mer­ci à Mme Claude, à M. Prot et à M. Farges, pour l’ensemble des efforts qu’ils mettent en œuvre pour nous appor­ter une for­ma­tion qua­li­ta­tive, mer­ci à eux pour leur accom­pa­gne­ment, leur écoute atten­tive et leur soutien.

Un remer­cie­ment par­ti­cu­lier à Mon­sieur Prot, qui a été mon inter­lo­cu­teur prin­ci­pal, en tant que tuteur d’université, et qui m’a déli­vré de pré­cieux conseils tout au long de mes 2 années d’études.

Je tiens éga­le­ment à remer­cier l’ensemble des ensei­gnants que j’ai eu lors de ma for­ma­tion en licence pro­fes­sion­nelle bio­mé­di­cal, et plus par­ti­cu­liè­re­ment Mme Mon­do­li­ni, M. Azan, M. Dubayle, Mme Lénat et M. Tome. En effet, ces der­niers m'ont fait décou­vrir en pro­fon­deur le domaine du dis­po­si­tif médi­cal, et les pers­pec­tives pro­fes­sion­nelles de ce der­nier, c’est éga­le­ment en par­tie grâce à leurs encou­ra­ge­ments, au tra­vers de recom­man­da­tion, que j’ai eu l’opportunité d’intégrer cette formation.

Mille mer­cis à Lida Farah, ma tutrice d’apprentissage, de m’avoir prise en tant qu’Apprentie Char­gée Affaires Règle­men­taires et Qua­li­té. J’ai eu l’opportunité de décou­vrir une per­sonne pro­fes­sion­nelle et pleine de bien­veillance. Cette alter­nance fut un réel chal­lenge, mais j’ai pu comp­ter sur son écoute, et je res­sors énor­mé­ment gran­dit de cette expé­rience dans mon domaine, tant sur le plan pro­fes­sion­nel que sur le plan humain. Mer­ci éga­le­ment à l’ensemble de l’équipe de ZOS IS pour leur accueil.

Pour ter­mi­ner, je tiens à remer­cier les per­sonnes qui comptent le plus dans ma vie : L’ensemble de ma famille et mes amis.

Mer­ci à ma mère de m’avoir encou­ra­gé tout au long de ma vie et de m’avoir sup­por­té, ain­si qu’à mon père de m’avoir orien­té et d’être res­té à mon écoute, même avec des mil­liers de kilo­mètres nous séparant.

Mer­ci éga­le­ment à Nol­wenn G., d’avoir tou­jours cru en moi, de m’avoir moti­vé et appor­té son sou­tien incon­di­tion­nel, et à Emma­nuel C. de m'avoir épau­lé durant ces deux années de mas­ter, de m’avoir récon­for­té dans les moments durs et d’être l’une de mes sources motrices les plus importantes.

Glossaire et abréviations

• Norme har­mo­ni­sée : Norme don­nant une pré­somp­tion de confor­mi­té à un texte règlementaire

• Règle­ments : Actes légis­la­tifs devant être mis en œuvre dans leur inté­gra­li­té sans trans­po­si­tion et sans inter­pré­ta­tion. Il s’applique en tant que tel à tous les états concernés.

• Direc­tive : Acte légis­la­tif fixant des objec­tifs et devant être trans­po­sé dans chaque pays concer­né et pour lequel une liber­té d’interprétation est possible.

• DM : Dis­po­si­tif Médical

• DMDIV : Dis­po­si­tif Médi­cal de Diag­nos­tic In Vitro

• SMQ : Sys­tème de Mana­ge­ment de la Qualité

• TPE : Très Petite Entreprise

• MDR : Médi­cal Device Regu­la­tion (Règle­ment 2017/745)

• ISO : Orga­ni­sa­tion Inter­na­tio­nale de normalisation

• NF : Norme Française

• EN : Norme Européenne

• SOUP : Soft­ware Of Unk­now Pedigree

Mémoire complet :

Mise en place d’un Système de Management de la Qualité, selon l’ISO 13485v2016 : Zoom sur la Validation des Applications Logicielles

Introduction

Les logi­ciels de san­té sont des tech­no­lo­gies numé­riques visant à gérer, à amé­lio­rer et à main­te­nir la san­té des indi­vi­dus ou des pres­ta­tions de soins [3].

Avec l’entrée en vigueur de la nou­velle règle­men­ta­tion autour des dis­po­si­tifs médi­caux (Règle­ment 2017/745), de nom­breux logi­ciels passent de la caté­go­rie de « simple » logi­ciel de san­té à dis­po­si­tif médi­cal et ce pas­sage s’accompagne d’un cadre juri­dique spé­ci­fique et beau­coup plus poin­tilleux que celui enca­drant les logi­ciels de santé.

L’enjeu est cru­cial dans le sec­teur de la san­té, car les logi­ciels régissent de plus en plus les acti­vi­tés en san­té, d’autant plus que la plu­part des socié­tés ayant déve­lop­pé un logi­ciel de san­té qui devient dis­po­si­tif médi­cal, mesurent rare­ment l’ampleur des exi­gences et démarches accom­pa­gnant la com­mer­cia­li­sa­tion d’un dis­po­si­tif médi­cal [4][5][6][7].

Ain­si, deux cas de figure peuvent se pré­sen­ter pour ces sociétés :

Soit, elles n’ont pas pu ou su mar­quer leur dis­po­si­tif médi­cal logi­ciel sous les direc­tives, avant la date de mise en appli­ca­tion du règle­ment (26 mai 2021), dans ce cas elles ne dis­posent pas de la période déro­ga­toire accor­dée aux dis­po­si­tifs mar­qués CE sous direc­tive, et doivent reti­rer leur logi­ciel du mar­ché euro­péen jusqu’à obte­nir le mar­quage CE.

Soit, elles ont pu mar­quer leur dis­po­si­tif médi­cal logi­ciel sous direc­tive, avant la date de mise en appli­ca­tion du règle­ment, elles dis­posent alors d’une période dite “période déro­ga­toire” jusqu’au 27 mai 2024, leur per­met­tant de conti­nuer à com­mer­cia­li­ser leur logi­ciel sur le mar­ché euro­péen (sous réserve d’être conforme aux dis­po­si­tions tran­si­toires de l’article 120 du règlement).

Mais, si elles sou­haitent main­te­nir leur logi­ciel dis­po­si­tif médi­cal sur le mar­ché euro­péen après le 27 mai 2024, ces der­nières doivent rapi­de­ment réa­li­ser la tran­si­tion vers le règle­ment euro­péen, car au-delà de cette date, les cer­ti­fi­cats de confor­mi­té obte­nus sous direc­tive sont ren­dus caduques, engen­drant un retrait immé­diat de ces DM [1].

Dans le cadre de ma der­nière année de Mas­ter, j’ai eu l’opportunité de tra­vailler au sein d’une entre­prise se trou­vant dans le 2^ème cas de figure et devant donc effec­tuer la tran­si­tion vers le règle­ment 2017/745.

Mon mémoire de fin d’alternance vient éclai­rer sur la mise en place d’un SMQ dans ce type de struc­ture, pour laquelle un sys­tème de mana­ge­ment de la qua­li­té n’est pas encore implé­men­té et se concen­tre­ra plus par­ti­cu­liè­re­ment sur une exi­gence spé­ci­fique de la norme 13485v2016 : Le point 4.1.6 concer­nant la « Vali­da­tion des appli­ca­tions logicielles ».

Chapitre 1 : ZOS Information System : De Logiciel de santé à Dispositif Médical Logiciel

Présentation de ZOS IS

Histoire de ZOS IS : L'association d'un directeur à son prestataire indépendant

ZOS Infor­ma­tion Sys­tem est une entre­prise créée en 2018 par M. Sou­hail Bou Kha­led, le diri­geant actuel de l’entreprise. C’est une entre­prise encore jeune qui est née d’une col­la­bo­ra­tion pérenne, de plus de 10 ans, entre un client (Mr Bou Kha­led), et son pres­ta­taire indépendant.

Le pres­ta­taire indé­pen­dant a donc com­men­cé à tra­vailler en col­la­bo­ra­tion avec Mr Bou Kha­led en free-lance, ZOS IS n’était pas encore créée.

Le diri­geant actuel de ZOS IS était alors déjà à la tête de plu­sieurs entre­prises du réseau de socié­tés “Elia médi­cal”, Pres­ta­taires de San­té à Domi­cile (PSAD) spé­cia­li­sés dans l’assistance res­pi­ra­toire à domicile.

Au début de cette col­la­bo­ra­tion, le pres­ta­taire avait été mis­sion­né pour mettre en place une inter­face (type « site web ») per­met­tant au PSAD Elia-Médi­cal, de gérer les ren­dez-vous des patients dont ils sont en charge. Le PSAD étant char­gé de la livrai­son, l’installation, le sui­vi et éga­le­ment la main­te­nance du maté­riel médi­cal et des trai­te­ments asso­ciés [8].

Au fur et à mesure du temps, les mis­sions confiées au pres­ta­taire indé­pen­dant sur l’interface ont évo­lué et se sont diver­si­fiées, et plu­sieurs fonc­tion­na­li­tés ont vu le jour sur l’interface ini­tia­le­ment deman­dée. La col­la­bo­ra­tion de ser­vice ini­tiale a alors natu­rel­le­ment abou­ti à une col­la­bo­ra­tion plus enca­drée, grâce à la créa­tion de ZOS IS par le client et l’embauche du pres­ta­taire en tant que pre­mier sala­rié de la socié­té nou­vel­le­ment fondée.

C’est à la suite de cela que le pro­duit de ZOS IS a vu le jour, I-GEIA est née. D’abord caté­go­ri­sé en tant que logi­ciel de san­té, il a ensuite été requa­li­fié en tant que dis­po­si­tif médical.

À noter que le nom I-GEIA vient de la mytho­lo­gie grecque, et plus pré­ci­sé­ment de la déesse HYGIE, déesse de la san­té, de la pro­pre­té et éga­le­ment de l'hygiène [9].

Organisation de ZOS IS

Zos Infor­ma­tion Sys­tem est actuel­le­ment une TPE (Très Petite Entre­prise), qui se reven­dique en tant que socié­té spé­cia­li­sée dans le déve­lop­pe­ment de solu­tions numé­riques sur mesure (logi­ciels, appli­ca­tions web et mobile), en asso­ciant inno­va­tion et appa­reils connec­tés. Elle s’est déve­lop­pée petit à petit, d’année en année et conti­nue encore à se déve­lop­per. Actuel­le­ment, elle compte 9 sala­riés stables et 2 étu­diants en appren­tis­sage [10].

Trois ser­vices peuvent être iden­ti­fiés au sein de la société :

• Le ser­vice recherche et déve­lop­pe­ment (R&D) : C’est le ser­vice en charge du déve­lop­pe­ment et de la main­te­nance du pro­duit. Il est com­po­sé d’une équipe de 4 déve­lop­peurs, enca­drée par un Res­pon­sable tech­nique et créa­tif. Un appren­ti déve­lop­peur a éga­le­ment inté­gré ZOS IS au cours de l’année 2021-2022 et pour­sui­vra nor­ma­le­ment son alter­nance durant l’année 2022-2023.
• Le ser­vice sup­port : Ce ser­vice est consti­tué d’une per­sonne char­gée du sup­port tech­nique, qui s’occupe de la ges­tion de l’ensemble des retours client et uti­li­sa­teur, et d’une Char­gée de com­mu­ni­ca­tion et de mar­ke­ting qui gère la mise en place d’une stra­té­gie de com­mu­ni­ca­tion à la fois en interne et éga­le­ment en externe pour faire connaitre les ser­vices offerts par l’entreprise, fidé­li­ser sa clien­tèle, atti­rer de nou­veaux clients et ain­si étendre son marché.
• Le ser­vice affaires régle­men­taires et qua­li­té : Ce ser­vice nou­vel­le­ment créé est en charge d’assurer la confor­mi­té de ZOS IS à l’ensemble des exi­gences qui lui sont appli­cables, de par la nature du pro­duit qu’il com­mer­cia­lise (un dis­po­si­tif médi­cal). Il compte pour l’instant une Res­pon­sable Qua­li­té et Affaires règle­men­taires, qui a été accom­pa­gné par moi-même, en tant qu’apprentie Char­gée affaires régle­men­taires et qualité.

L’organigramme sui­vant (figure 1) repré­sente l’organisation hié­rar­chique de ZOS IS en date actuelle :

Figure 1 : Organigramme de ZOS IS. Source : Auteure

L’ensemble des sala­riés sont répar­tis dans deux locaux dif­fé­rents. Un local se situe à Bou­logne-Billan­court et regroupe le ser­vice R&D et le ser­vice sup­port. Le ser­vice affaires régle­men­taires et qua­li­té est quant à lui délo­ca­li­sé aux Loges-en-Josas, pour des rai­sons de limi­ta­tion en termes d’espace dans les locaux de Boulogne-Billancourt.

Les clients de ZOS IS sont les socié­tés du réseau d’Elia médi­cal ain­si que d’Univ’air médi­cal, éga­le­ment Pres­ta­taires de San­té à Domi­cile spé­cia­li­sés dans l’assistance res­pi­ra­toire à domi­cile [8].

Présentation du produit commercialisé par ZOS IS

I-GEIA : Vers une télésurveillance ultra-performante des patients en assistance respiratoire

ZOS IS se concentre actuel­le­ment sur un unique pro­duit, le dis­po­si­tif médi­cal I-GEIA. L’équipe étant rela­ti­ve­ment petite, com­pa­rée à la charge de tra­vail, il est actuel­le­ment dif­fi­cile pour l’entreprise d’élargir son por­te­feuille produit.

I-GEIA était donc à la base un “simple” logi­ciel de san­té, mais les demandes récur­rentes d’amélioration venant des clients et uti­li­sa­teurs ont conduit à l’ajout de fonc­tion­na­li­té fai­sant bas­cu­ler le logi­ciel de san­té dans la caté­go­rie bien par­ti­cu­lière des dis­po­si­tifs médi­caux, sou­met­tant ain­si le logi­ciel aux obli­ga­tions éta­blis dans le règle­ment 2017/745.

I-GEIA est une pla­te­forme infor­ma­tique per­met­tant le sui­vi des per­sonnes en assis­tance res­pi­ra­toire qui font de l’apnée du sommeil.

L’apnée du som­meil, ou syn­drome d’apnées-hypopnées obs­truc­tives du som­meil, est une patho­lo­gie qui se tra­duit par des arrêts res­pi­ra­toires répé­tés et incon­trô­lés, qui conduisent à des micro-réveils constants du patient, qui n’en a pour­tant pas conscience.

Le nombre d’individus souf­frant de ce syn­drome est en aug­men­ta­tion au fur et à mesure de l’amélioration des tech­niques de diag­nos­tic, et est à l’origine de nom­breux troubles tels que les ron­fle­ments, la fatigue chro­nique, la som­no­lence diurne (en pleine jour­née), les troubles car­dio­vas­cu­laires, voir même le décès du patient etc.

Aus­si, un sui­vi régu­lier et pré­cis de ces patients est néces­saire pour limi­ter ces troubles [11], [12].

Ain­si, le logi­ciel i-GEIA per­met aux Pres­ta­taires de San­té à Domi­cile, spé­cia­li­sés dans l’assistance res­pi­ra­toire, et aux méde­cins pres­crip­teurs d’accéder d’une manière numé­rique aux don­nées des patients appa­reillés d’un dis­po­si­tif res­pi­ra­toire. Il per­met de sto­cker les dos­siers patients pour four­nir un sui­vi de l’historique de l’appareillage et des inter­ven­tions effec­tuées au domi­cile du patient. 

Pour les patients équi­pés d’appareils connec­tés (ven­ti­la­tion assis­tée ou appa­reil à pres­sion posi­tive conti­nue), le logi­ciel recueille les don­nées d’observances des ser­veurs des fabri­cants par une inter­face de pro­gram­ma­tion d’application (API) et les trans­forme en gra­phiques pour faci­li­ter la lec­ture. Le logi­ciel génère ain­si une liste d’alertes médi­cales selon un algo­rithme et des cri­tères définis. 

Le logi­ciel com­prend plu­sieurs fonc­tion­na­li­tés et existe sous quatre configurations : 

• I-GEIA pour le PSAD est sous le sup­port d’une appli­ca­tion web : Le PSAD repré­sente l’entité en charge du maté­riel médi­cal, de son ins­tal­la­tion ain­si que de sa main­te­nance. Il consti­tue l’intermédiaire pri­vi­lé­gié entre le patient, chez qui le maté­riel est ins­tal­lé, et le méde­cin pre­nant en charge ce patient (méde­cin ORL, méde­cin géné­ra­liste, car­dio­logue, neurologue …). 

• I-GEIA pour les tech­ni­ciens est sous le sup­port d’une appli­ca­tion mobile : Les tech­ni­ciens font par­tie du per­son­nel du PSAD et sont notam­ment en charge de l’installation et des visites chez les dif­fé­rents patients. L’application leur per­met de sai­sir les don­nées lors de leurs visites aux domi­ciles des patients. 

• I-GEIA pour les méde­cins est sous le sup­port d’une appli­ca­tion web : Le méde­cin est la per­sonne qui suit le patient et qui lui a pres­crit la machine médi­cale. Le logi­ciel per­met au méde­cin pres­crip­teur de suivre les don­nées d’observance de ses patients. Les don­nées d’observance sont : 
  • L’index apnée/hypopnées : il repré­sente les apnées non cor­ri­gées par l’appareil 
  • Les fuites aux masques : elles peuvent être le signe d’un pro­blème d’adaptation du masque à la mor­pho­lo­gie faciale du patient. 
  • La durée d’utilisation de l’appareil par le patient : qui per­met de consta­ter la bonne uti­li­sa­tion ou non par le patient de son traitement. 
  • La pres­sion efficace 

Il per­met éga­le­ment de visua­li­ser les jours où une alerte médiale a été détec­tée chez un patient, ain­si que de visua­li­ser les visites effec­tuées par le PSAD chez le patient (à la suite d’une alerte ou lors d’une visite de sui­vi habi­tuelle). Ces dif­fé­rents indi­ca­teurs vont donc don­ner dif­fé­rentes indi­ca­tions per­met­tant d’améliorer la prise en charge du patient. 

• I-GEIA pour les patients : I-GEIA patient peut être pré­sent sous le sup­port à la fois d’une appli­ca­tion web et d’une appli­ca­tion mobile. L’application per­met à chaque patient d’être un acteur cen­tral de sa san­té. En effet, le patient peut suivre quo­ti­dienne et faci­le­ment plu­sieurs de ces para­mètres, mais aus­si contac­ter, au tra­vers de l’application, son méde­cin ou le PSAD pour toute interrogation. 

Le tableau ci-des­sous (tableau 1) pré­sente un résu­mé des dif­fé­rentes pla­te­formes et des uti­li­sa­teurs associés :

Tableau 1 : Récapitulatif des configurations de i-GEIA. Source : Auteure

I-GEIA se déve­loppe de jour en jour et les demandes d’améliorations en termes de modi­fi­ca­tion ou d’ajout de fonc­tion­na­li­té ne cesse d’augmenter.

Le logi­ciel tend par ailleurs à implé­men­ter une fonc­tion­na­li­té d’aide à la déci­sion, per­met­tant au méde­cin, au tra­vers de réponse à diverses ques­tions et d’un bilan final, de prendre des déci­sions concer­nant la modi­fi­ca­tion du trai­te­ment du patient.

I-GEIA sur le marché français

La réa­li­sa­tion d’une ana­lyse concur­ren­tielle du mar­ché auquel se confronte I-GEIA, a per­mis d’identifier 2 concur­rents principaux :

• Adel san­té par Datamedcare

Adel san­té est une pla­te­forme de télé-sui­vi qui col­lecte et agrège des don­nées de san­té pro­ve­nant de dif­fé­rents types de dis­po­si­tif médi­cal, pour les mettre à la dis­po­si­tion des dif­fé­rents acteurs du par­cours de soin. Adel san­té gère comme I-GEIA des patients atteints de patho­lo­gies res­pi­ra­toires [13].

• MUST-G5 (Orthop) par Must Informatique

MUST-G5 est un outil infor­ma­tique dédié au PSAD per­met­tant de gérer leur inter­ven­tion (pla­ni­fi­ca­tion...), les rap­ports d’intervention ain­si que la fac­tu­ra­tion SESAM-Vitale et SCOR (l’envoi de feuilles de soins sous for­mat élec­tro­nique à l’assurance mala­die et aux orga­nismes d’assurance mala­die com­plé­men­taire). MUST-G5 gère comme I-GEIA des patients atteints de patho­lo­gies res­pi­ra­toires [14].

D’autres concur­rents indi­rects peuvent être éga­le­ment cités tel que Resmed avec leur logi­ciel Air­View ou Phil­lips res­pi­ro­nix dream sta­tion, mais ces der­niers mettent en place ce type d’outil direc­te­ment inté­grer à leur propre appa­reil res­pi­ra­toire qu’ils fabriquent [15], [16].

Peu d’informations sont trou­vables sur ces diverses tech­no­lo­gies pour per­mettre d’effectuer un com­pa­ra­tif signi­fi­ca­tif et pertinent.

ZOS IS : Une entreprise jeune et prometteuse avec une organisation interne à développer

Figure 2 : SWOT de ZOS IS. Source : Auteure

Le SWOT ou MOFF en fran­çais est une ana­lyse glo­bale d’une entre­prise, per­met­tant d’évaluer ses forces et fai­blesses ain­si que d’identifier les oppor­tu­ni­tés pou­vant s’offrir à elle et les menaces aux­quelles elle pour­rait être confrontée.

L’analyse de l’entreprise par le SWOT (figure 2) montre que les forces et donc points forts de l’entreprise à déve­lop­per réside dans ses res­sources humaines, qui sont des sala­riés jeunes et dyna­mique [17]. La per­ti­nence de leur pro­duit est éga­le­ment un atout impor­tant (patho­lo­gies res­pi­ra­toires en hausses d’années en années) [18].

Les fai­blesses de l’entreprise et donc les points d’amélioration pour les­quels cette der­nière doit por­ter une atten­tion par­ti­cu­lière, afin de res­ter per­for­mante sur son mar­ché sont notamment :

• Réflé­chir sur l’éventualité d’étendre son por­te­feuille pro­duit afin que son chiffre d'affaires ne soit plus dépen­dant d’un seul et unique produit
• Trou­ver des locaux, aus­si bien loca­li­sé que ceux de Bou­logne, suf­fi­sam­ment grand pour accueillir l’ensemble des ser­vices et suf­fi­sam­ment agen­cé pour per­mettre une meilleure cohé­sion de groupe
• Amé­lio­ra­tion de l’attractivité de la socié­té et de sa poli­tique d’intégration des sala­riés pour limi­ter le turn-over et favo­ri­ser une atmo­sphère de tra­vail plus stimulante
• Réflé­chir sur une stra­té­gie per­met­tant d’étendre son por­te­feuille client

Plu­sieurs oppor­tu­ni­tés s’offrent éga­le­ment à l’entreprise, telles que l’expansion de la e-San­té, offrant une réflexion sur la pos­si­bi­li­té de conce­voir un nou­veau pro­duit entrant dans le cadre de la e-san­té, mais éga­le­ment le nou­veau cadre juri­dique s’imposant à l’entreprise, qui va per­mettre d’améliorer de façon notable la qua­li­té des pra­tiques en interne, mais éga­le­ment l’image ren­voyée par la société.

L’entreprise devra faire éga­le­ment atten­tion à cer­tains points externes à son orga­ni­sa­tion, qui pour­raient l’impacter négativement :

• La date butoir (27 mai 2024) à laquelle les dis­po­si­tifs médi­caux mar­qué CE sous direc­tives ne pour­ront plus être com­mer­cia­li­sés, si ces der­niers n’ont pas obte­nu le mar­quage CE sous le règle­ment 2017/745. ZOS IS doit donc impé­ra­ti­ve­ment réa­li­ser sa tran­si­tion « direc­tive -> règle­ment » et obte­nir son mar­quage CE, si elle sou­haite main­te­nir son DM sur le marché
• Une veille concur­ren­tielle doit éga­le­ment être effec­tué afin d’assurer la plus-value de son outil par rap­port aux outils simi­laires se développant

ZOS IS est une socié­té en plein essor dont les pers­pec­tives de déve­lop­pe­ment sont mul­tiples et doivent pas­ser par une amé­lio­ra­tion de son orga­ni­sa­tion interne. Une amé­lio­ra­tion du sui­vi et des besoins des sala­riés pour­rait per­mettre un meilleur épa­nouis­se­ment de ses der­niers et une amé­lio­ra­tion de leur effi­ca­ci­té et effi­cience. L’entreprise à un large panel de clien­tèle poten­tiel auquel il serait inté­res­sant qu’elle réus­sisse à s’ouvrir, le désir de recru­te­ment de nou­veau sala­rié tend à se concré­ti­ser et per­met­trait éga­le­ment d’augmenter les per­for­mances de l’entreprise.

Chapitre 2 : Vision macro de la mise en place d'un Système de Management de la Qualité selon l'ISO 13485 : 2016

Présentation de la norme et des points principaux

La nou­velle règle­men­ta­tion autour des dis­po­si­tifs médi­caux expli­cite la néces­si­té de mettre en place un sys­tème de ges­tion de la qua­li­té pour tout fabri­cant de dis­po­si­tifs médi­caux. Ce sys­tème de ges­tion de la qua­li­té doit garan­tir la confor­mi­té au règlement.

Le règle­ment nous donne le « Quoi », c’est-à-dire « quoi faire », mais ne nous donne pas le « com­ment », c’est-à-dire le “com­ment faire”. Pour savoir « com­ment faire » et donc com­ment appli­quer les exi­gences pour être conforme à la règle­men­ta­tion, l’utilisation des normes har­mo­ni­sées est une solu­tion pertinente.

ZOS IS déve­loppe un dis­po­si­tif médi­cal logi­ciel, ain­si la mise en place d’un sys­tème de ges­tion de la qua­li­té est obli­ga­toire. Une norme har­mo­ni­sée existe, per­met­tant de don­ner la pré­somp­tion de confor­mi­té à cer­tains points exi­gés par le règle­ment, concer­nant le sys­tème de ges­tion de la qua­li­té : C’est la norme ISO 13485 : 2016 “Dis­po­si­tifs médi­caux - Sys­tèmes de mana­ge­ment de la qua­li­té - Exi­gences à des fins régle­men­taires”.

L’ISO 13485 est la norme par excel­lence uti­li­sée dans le domaine du dis­po­si­tif médi­cal pour mettre en place un sys­tème de mana­ge­ment de la qua­li­té, per­met­tant de démon­trer l’« apti­tude [des entre­prises du DM] à four­nir régu­liè­re­ment des dis­po­si­tifs médi­caux et des ser­vices asso­ciés conformes aux exi­gences des clients et aux exi­gences régle­men­taires appli­cables » [19].

En sui­vant cette norme, ZOS IS pour­ra se confor­mer en par­tie aux exi­gences deman­dées par le règle­ment pour la mise en place d’un sys­tème de ges­tion de la qua­li­té. « En par­tie » signi­fie que l’application com­plète de cette norme ne garan­tis pas la confor­mi­té totale à l’exigence du règle­ment. Pour déter­mi­ner les par­ties cou­vertes, par­tiel­le­ment cou­vertes ou non cou­vertes par la norme, il existe le réfé­ren­tiel NF EN ISO 13485/A11 : 2021, qui vient expli­ci­ter le degré de cou­ver­ture, au tra­vers des annexes Z [20], [21].

ZOS IS étant dans un pre­mier temps une socié­té déve­lop­pant un pro­duit de type logi­ciel de san­té, la mise en place d’un SMQ et donc l’instauration d’une poli­tique et d’une culture qua­li­té n’était ni une obli­ga­tion, ni une pré­oc­cu­pa­tion pre­mière de la socié­té. De ce fait, ZOS IS, lors du début de l’alternance, n’avait pas encore débu­tée sa démarche de mise en place d’un SMQ. Il exis­tait donc très peu de docu­men­ta­tion pou­vant ser­vir de base à l’implémentation d’un SMQ.

Une pre­mière étape était donc d’étudier la norme ISO 13485 : 2016, afin d’identifier l’ensemble des exi­gences de cette norme et de déter­mi­ner quelles étaient celles appli­cables à l’entreprise et à son pro­duit (Dis­po­si­tif Médi­cal actif de classe IIa).

En effet, il existe des par­ties de cette norme qui ne s’applique pas à toute entre­prise et à tout dispositif.

Par exemple l’exigence 7.5.2 “Pro­pre­té du pro­duit” n’est pas appli­cable à ZOS IS de par la nature de son dis­po­si­tif (logi­ciel en tant que dis­po­si­tif médi­cal) ce der­nier ne peut pas être sou­mis à des phé­no­mènes de conta­mi­na­tion bio­lo­gique, car il n’est pas en contact direct de l’humain, ou encore le point 7.5.5 qui s’adresse à des dis­po­si­tifs médi­caux spé­ci­fiques, les dis­po­si­tifs médi­caux sté­riles [19].

Une fois cette ana­lyse de la norme effec­tuée et cette déter­mi­na­tion des exi­gences appli­cables, qui ont été agen­cées sous forme de tableau, afin de faci­li­ter la visi­bi­li­té de l’ensemble des exi­gences (Annexe 1), la mise en appli­ca­tion de ces der­nières a été pla­ni­fiée et réalisée.

L’ensemble des exi­gences de la norme s’articulent autour de 5 points :

A) La mise en place d’un sys­tème de mana­ge­ment de la qualité

Point cen­trale de la norme, la mise en place d’un SMQ s’axe sur l’approche pro­ces­sus. L’approche pro­ces­sus per­mets à un orga­nisme de struc­tu­rer l’ensemble de ses acti­vi­tés tout au long du cycle de vie de ses DM.

Pour mettre en place l’approche pro­ces­sus, l’organisme doit d’abord iden­ti­fier l’ensemble des pro­ces­sus qui inter­viennent au sein de sa structure.

Un pro­ces­sus repré­sente une acti­vi­té ou un ensemble d’activités, réalisée(s) dans l’entreprise, qui trans­forment des élé­ments d’entrée en élé­ments de sortie.

Par exemple, si l’on prend un exemple de la vie quo­ti­dienne et que l’on consi­dère donc l’activité « Nour­rir sa famille », comme un pro­ces­sus alors l’élément d’entrée pour­ra être « La famille est affa­mée » et l’élément de sor­tie « La famille est nourrie ».

Un exemple de pro­ces­sus interne à l’entreprise qui a pu être iden­ti­fié au sein de ZOS IS est le sous-pro­ces­sus « Trai­ter les récla­ma­tions », l’élément d’entrée étant « Récla­ma­tions des uti­li­sa­teurs » et les élé­ments de sor­tie étant « Modi­fi­ca­tion du logi­ciel » et « Noti­fi­ca­tions (fiches d’avertissements) ».

Les pro­ces­sus peuvent être regroupés/subdivisés en 3 macro-pro­ces­sus (ensemble cohé­rent per­met­tant de ras­sem­bler plu­sieurs pro­ces­sus ou sous pro­ces­sus en grand domaine) :

• Les pro­ces­sus de management/pilote : Ils repré­sentent les pro­ces­sus qui viennent pilo­ter la démarche qua­li­té et en assu­rer son amé­lio­ra­tion continue. 
• Les pro­ces­sus de réa­li­sa­tion : Ils repré­sentent les pro­ces­sus cen­traux de l’entreprise. En effet, ce sont les pro­ces­sus qui vont contri­buer direc­te­ment à la réa­li­sa­tion de(s) élément(s) de sor­tie (ser­vice ou pro­duit) offert(s) par l’entreprise (de l’identification du besoin client jusqu’à sa satisfaction).
• Les pro­ces­sus sup­port : Ils repré­sentent les pro­ces­sus qui vont par­ti­ci­per au bon dérou­le­ment de l’ensemble des autres pro­ces­sus. En effet, ils vont four­nir aux autres pro­ces­sus les res­sources néces­saires pour leur fonc­tion­ne­ment cor­rect (maté­rielles et imma­té­rielles) [22].

Une fois les pro­ces­sus iden­ti­fiés, il faut les orga­ni­ser dans la logique entre­prise. Pour cela, chaque pro­ces­sus peut être clas­sé dans un des 3 macro-pro­ces­sus pré­cé­dem­ment cités.

Il est à noter que la clas­si­fi­ca­tion des pro­ces­sus dans ces trois macro-pro­ces­sus peut varier d’une entre­prise à une autre. Par exemple : le pro­ces­sus “main­te­nance infor­ma­tique” en fonc­tion de sa des­ti­na­tion (des­ti­na­tion de client finaux ou à des­ti­na­tion de ser­vice de pro­duc­tion interne) fera soit par­tie du macro-pro­ces­sus réa­li­sa­tion, car il contri­bue­ra direc­te­ment à la réa­li­sa­tion du ser­vice ou du pro­duit, ou bien il fera par­tie du macro-pro­ces­sus sup­port, car il inter­vien­dra en tant qu’aide au main­tien des dif­fé­rentes acti­vi­tés. Dans le cas de l’entreprise ZOS IS par exemple, nous avons posi­tion­né le pro­ces­sus main­te­nance (infor­ma­tique), dans le pro­ces­sus de réa­li­sa­tion, car la main­te­nance de notre logi­ciel dis­po­si­tif médi­cal par­ti­cipe direc­te­ment à la réa­li­sa­tion de notre produit.

Les pro­ces­sus ain­si regrou­pés en macro-pro­ces­sus, une car­to­gra­phie des pro­ces­sus peut être réalisée.

La car­to­gra­phie des pro­ces­sus est une repré­sen­ta­tion visuelle per­met­tant de mettre en évi­dence les inter­ac­tions entre les pro­ces­sus, de façon sim­pli­fiée et illus­trée, et donc plus com­mu­ni­ca­tif pour l’ensemble du personnel.

Le choix de la repré­sen­ta­tion de la car­to­gra­phie (figure 3) est lais­sé à la libre appré­cia­tion de la per­sonne en charge de sa réa­li­sa­tion, cepen­dant les car­to­gra­phies pro­ces­sus sont géné­ra­le­ment repré­sen­tées avec une struc­ture de ce type :

Figure 3 Exemples de cartographie de processus. Sources : Stratégik, Qualitexpert, Advaloris

Enfin, chaque pro­ces­sus au sein de la struc­ture doit être mai­tri­sé, et leur mai­trise passe par une approche fon­dée sur les risques (ana­lyse des risques des dif­fé­rents pro­ces­sus afin d’identifier les acti­vi­tés cri­tiques et de mettre en place, si néces­saire, des actions pro­por­tion­nées) [23].

B) La res­pon­sa­bi­li­té de la direction

Point non-négli­geable, la res­pon­sa­bi­li­té de la direc­tion dans la norme est clai­re­ment explicitée.

La norme indique que la direc­tion doit faire preuve d’engagement dans la démarche de mise en place d’un SMQ. Cet enga­ge­ment passe notam­ment au tra­vers de l’établissement d’une poli­tique qua­li­té, par la direc­tion, au tra­vers d’une pla­ni­fi­ca­tion d’objectifs qualités.

Cette poli­tique qua­li­té décrit les axes stra­té­giques de l’entreprises, le(s) but(s), l(es) objectif(s) de l’entreprise et la direc­tion dans laquelle cette der­nière sou­haite aller. Elle est essen­tielle et doit être connue de l’ensemble des sala­riés, car elle vise à diri­ger l’entreprise et à lui per­mettre, au tra­vers de l’atteinte des objec­tifs, d’améliorer conti­nuel­le­ment son acti­vi­té. Elle est éga­le­ment un outil de mana­ge­ment non-négli­geable, si elle est uti­li­sée à bon escient, en fédé­rant les col­la­bo­ra­teurs autour des axes stra­té­giques com­muns de l’entreprise.

La direc­tion devra éga­le­ment sen­si­bi­li­ser ses sala­riés en com­mu­ni­quant régu­liè­re­ment et dès que néces­saire sur la qua­li­té (et notam­ment la poli­tique et les objec­tifs qualité).

Sou­vent négli­gée par les entre­prises, la res­pon­sa­bi­li­té de la direc­tion est pour­tant le point moteur de la mise en place effi­cace d’un sys­tème de mana­ge­ment de la qua­li­té performant.

En effet, l’attribution des res­sources est dépen­dante de la direc­tion, une direc­tion qui ne met­tra pas en place les res­sources néces­saires à l’avancé et à l’efficacité de la mise en place du SMQ, contri­bue­ra à un ralen­tis­se­ment consi­dé­rable de sa bonne mise en place, et pour­ra même conduire à des non-confor­mi­tés (SMQ mis en place mais non-conforme). Sans l’appui de la direc­tion les res­sources néces­saires sont très limi­tées pour la mise en place d’un SMQ performant.

C) Le mana­ge­ment des ressources

Lié comme décrit pré­cé­dem­ment à la direc­tion, le mana­ge­ment des res­sources au sein de l’organisme est fondamental.

En effet, il faut s’assurer que l’ensemble des res­sources néces­saires sont, tout au long du cycle de vie du dis­po­si­tif médi­cal, dis­po­nibles et exploi­tables (humaines, matérielles...).

Ces res­sources vont per­mettent notam­ment de satis­faire et ain­si répondre aux exi­gences règle­men­taires appli­cables, aux exi­gences en termes d’infrastructure, en termes d’environnement de tra­vail et en termes de com­pé­tence des acteurs de la qualité.

La norme ISO 13485 : 2016 exige ain­si que l’organisme soit en capa­ci­té de four­nir les res­sources adé­quates à la mise en place et au main­tien du sys­tème de mana­ge­ment de la qua­li­té, et éga­le­ment capable de four­nir des preuves de la qua­li­fi­ca­tion du per­son­nel clé dans le SMQ.

D) La réa­li­sa­tion du produit

Dans le cadre de l’ISO 13485 le pro­duit est un dis­po­si­tif médical.

La norme centre la réa­li­sa­tion du pro­duit sur la mai­trise des risques. Le DM doit ain­si être conçu, déve­lop­pé et pro­duit en mini­mi­sant au maxi­mum les risques liés à la concep­tion, à l’aptitude à l’utilisation, à la pro­duc­tion, à l’achat de com­po­sant ou de matière pre­mière, au trans­port etc...

L’organisme doit pou­voir four­nir les preuves de ses acti­vi­tés de ges­tion des risques en tenant notam­ment un registre.

Lors de la réa­li­sa­tion du pro­duit la norme exi­gence éga­le­ment que plu­sieurs fac­teurs soient pris en compte tel que l’environnement de tra­vail, le contrôle de la conta­mi­na­tion (non appli­cable dans le cas de ZOS IS, comme vu pré­cé­dem­ment), l’infrastructure de l’entreprise, la mani­pu­la­tion du pro­duit (non appli­cable à ZOS IS), le sto­ckage adé­quat du pro­duit (non appli­cable à ZOS IS), les méthodes de dis­tri­bu­tion, la tra­ça­bi­li­té du produit.

E) Le mesu­rage, l’analyse et l’amélioration

Enfin, une fois que l’ensemble des exi­gences de la norme sont appli­quées au sein de l’organisme, la bonne appli­ca­tion de la norme ne s’arrête pas là.

En effet, il ne suf­fit pas d’appliquer les exi­gences, il faut s’assurer que ces exi­gences soient tou­jours exé­cu­tées et conformes dans le temps.

Ce der­nier point implé­mente cette néces­si­té. En effet, la norme ISO 13485 exige que les pro­duits, les pro­ces­sus et les ser­vices soient sur­veiller et mesu­rer au regard des objec­tifs pré­dé­fi­nis, des exi­gences et des acti­vi­tés pla­ni­fiés, pour rendre compte des résultats.

L’organisme doit réa­li­ser et mettre en œuvre des pro­cé­dures qua­li­té, ou des méthodes pour s’assurer que le pro­duit répond ou dépasse toutes les exi­gences du client et/ou de la régle­men­ta­tion. De plus, des don­nées doivent être col­lec­tées et ana­ly­sées afin de s’assurer de l’efficacité du SMQ mis en place. Les don­nées devront prendre en compte les infor­ma­tions recueillies à par­tir des audits et de la mesure des pro­ces­sus (au tra­vers d’indicateur) et du pro­duit ain­si que des retours des clients et des four­nis­seurs [24][25][26].

Pour répondre à l’ensemble des points pré­ci­tés, il est impor­tant de se posi­tion­ner sur l’état d’avancement de l’application des exi­gences. L’outil d’autodiagnostique de l’ISO 13485 : 2016 réa­li­sé par des étu­diants de l’UTC, a été effec­tué après quelques mois pas­sés en entre­prise (figure 4).

Cet outil a pu mon­trer que nous avions pro­gres­ser dans la mise en place du SMQ, mais que nous avions encore une quan­ti­té impor­tante d’exigence à mettre en place, et notam­ment au niveau de l’article 8 “Mesu­rage, ana­lyse et amé­lio­ra­tion” et de l’article 5 “Res­pon­sa­bi­li­té de la direction”.

Figure 4 Autodiagnostique de ZOS IS sur sa conformité à l'ISO 13485v2016 après quelques mois passés en entreprise

Aus­si, autour de ces points s’articule une exi­gence fon­da­men­tale : la mise en place d’un sys­tème documentaire.

Aide à la rédaction du système documentaire du SMQ

La mise en place d’un sys­tème docu­men­taire est l’une des exi­gences qui a été prin­ci­pa­le­ment mise en place lors de l’alternance. Le sys­tème docu­men­taire est l’un des élé­ments cen­traux de la norme. Il repré­sente l’ensemble des docu­ments que l’entreprise doit réa­li­ser et qui ser­vi­ront de preuve de la bonne mise en place du SMQ.

Le sys­tème docu­men­taire deman­dé par la norme est rela­ti­ve­ment impo­sant, en effet, en une norme on décompte 103 preuves docu­men­taires évo­quées (obli­ga­toires pour la plu­part, et condi­tion­nelles pour cer­taines). Par­mi elles, on retrouve 30 pro­cé­dures, 48 enre­gis­tre­ments, et 25 docu­ments autres [27].

Les pro­cé­dures repré­sentent une façon spé­ci­fiée d’effectuer une acti­vi­té (et donc un pro­ces­sus), elles consistent en un des­crip­tif orga­ni­sa­tion­nel et détaillé, per­met­tant de mener à la réa­li­sa­tion du processus/de l’activité associé.

Ain­si, si une pro­cé­dure n’est pas sui­vie, il est fort pro­bable que les don­nées de sor­ties du pro­ces­sus ne soient pas conformes aux exi­gences atten­dues [22]. Par­mi les pro­cé­dures exi­gées par la norme, qui ont pu être réa­li­sées au sein de l’entreprise ZOS IS, on retrouve :

• La pro­cé­dure « Revue de direction »
• La pro­cé­dure « Trai­te­ment des réclamations »
• La pro­cé­dure « dif­fu­sion des fiches d’avertissement »
• La pro­cé­dure « Ges­tion des res­sources humaines »

Une pro­cé­dure est donc très sou­vent asso­ciée à un pro­ces­sus, la norme exige que des pro­ces­sus existent pour plu­sieurs acti­vi­tés. Pour gar­der une preuve, les pro­ces­sus peuvent être docu­men­tés sous forme de fiche de processus.

Par­mi les pro­ces­sus exi­gés par la norme et géné­ra­le­ment pré­sents chez tout fabri­cant de dis­po­si­tifs médi­caux, on peut retrouver :

• Le pro­ces­sus « ges­tion des retours d’informations »
• Le pro­ces­sus « ges­tion des réclamations »
• Le pro­ces­sus « mai­trise des non-conformités »
• Le pro­ces­sus « Noti­fi­ca­tion aux auto­ri­tés compétentes »
• Le pro­ces­sus « Ges­tion des actions cor­rec­tives et préventives »

Les enre­gis­tre­ments repré­sentent des preuves de la bonne exé­cu­tion d’une acti­vi­té exi­gée par la norme. Par exemple, la norme exige que l’organisme s’assure que son per­son­nel pos­sède les com­pé­tences néces­saires, lorsque que le tra­vail qu’il réa­lise peut avoir une inci­dence sur la qua­li­té, et que la preuve de ses com­pé­tences et éga­le­ment de la bonne réa­li­sa­tion de ses for­ma­tions soit conser­vée sous forme d’un enregistrement.

Les 25 autres docu­ments exi­gés par la norme repré­sentent des docu­ments annexes aux pro­cé­dures et aux enre­gis­tre­ments, tels que le manuel qua­li­té, le dos­sier du dis­po­si­tif médi­cal, ou encore le dos­sier de conception.

Pour réa­li­ser l’ensemble des docu­ments exi­gés, la métho­do­lo­gie sui­vante a été appliquée :

En pre­mier lieu, il faut s’assurer d’avoir cor­rec­te­ment sai­si ce qui est exi­gé en termes de conte­nu dans le docu­ment, la forme peut éga­le­ment avoir une impor­tance en fonc­tion du docu­ment, mais est géné­ra­le­ment lais­sé à la libre appré­cia­tion du rédacteur.

Une pre­mière recherche est réa­li­sée pour déter­mi­ner l’utilité et le but du docu­ment, et ain­si avoir une idée glo­bale de ce qui pour­rait être atten­du par ce document.

Ensuite, la recherche de dif­fé­rents modèles acces­sibles, pour avoir une base sur la struc­ture du docu­ment et notam­ment sur le conte­nu pou­vant être atten­du par ce der­nier, est réa­li­sée (cette étape n’est pas tou­jours pos­sible, car cer­tains docu­ments n’existent pas en libre accès).

Enfin, pour les docu­ments qui concernent direc­te­ment ou indi­rec­te­ment des membres du per­son­nel, tels que les pro­cé­dures, une inter­ro­ga­tion a été menée pour obte­nir des infor­ma­tions sur l’état actuel des choses. Par exemple, pour les pro­cé­dures déjà réa­li­sées en interne de façon infor­melle, le per­son­nel jouant un rôle dans la pro­cé­dure a été inter­ro­gé afin de se ren­sei­gner sur leur façon actuelle de procéder.

Par la suite, en com­pa­rant ce qui était fait à ce qui pou­vait être atten­du, des docu­ments ont pu être réa­li­sés, en pre­nant en compte les pra­tiques internes (afin de ne pas bou­le­ver­ser les membres du per­son­nel et conser­ver ce qui était déjà cor­rec­te­ment réa­li­sé en interne), mais éga­le­ment en véri­fiant si tout ce qui était atten­du était rem­pli, et si cela n’était pas le cas les infor­ma­tions man­quantes étaient rajou­tés aux infor­ma­tions collectées.

Une fois les docu­ments réa­li­sés, ces der­niers ont été pré­sen­tés à la Res­pon­sable Qua­li­té et Affaires Règle­men­taires afin qu’elle apporte les cor­rec­tions nécessaires.

Le sys­tème docu­men­taire du SMQ peut être struc­tu­ré sous forme pyra­mi­dale (figure 5), du déploie­ment de la stra­té­gie de l’entreprise au tra­vers de la poli­tique qua­li­té, à la réa­li­té opé­ra­tion­nelle du terrain.

Figure 5 Exemple du système documentaire du SMQ organisé sous forme pyramidale. Source : QualitExpert

Chapitre 3 : Validation des applications logicielles

Présentation de la validation des applications logicielles : Une exigence cruciale, bien souvent négligée

La vali­da­tion des appli­ca­tions logi­cielles est une des exi­gences nou­vel­le­ment appor­tées par la révi­sion de l’ISO 13485 : 2003.  En effet, l’ISO 13485 : 2016, évoque à plu­sieurs reprises la néces­si­té de vali­der les « appli­ca­tions logicielles » :

• Au point 4.1.6 la norme exige que « L’organisme docu­mente des pro­cé­dures pour la vali­da­tion des appli­ca­tions logi­cielles uti­li­sées dans le sys­tème de mana­ge­ment de la qua­li­té. Ces appli­ca­tions logi­cielles doivent être vali­dées avant leur pre­mière uti­li­sa­tion et, lorsque appro­prié, après la modi­fi­ca­tion de ce logi­ciel ou de son application »
• Au point 7.5.6 elle évoque que « L’organisme doit docu­men­ter des pro­cé­dures pour la vali­da­tion des appli­ca­tions logi­cielles uti­li­sées en pro­duc­tion et dans le cadre des pres­ta­tions de ser­vice. Ces appli­ca­tions logi­cielles doivent être vali­dées avant leur pre­mière uti­li­sa­tion et, lorsque appro­prié, après la modi­fi­ca­tion de ce logi­ciel ou de son application »
• Enfin, au point 7.6 elle men­tionne que « L’organisme doit docu­men­ter des pro­cé­dures pour la vali­da­tion des appli­ca­tions logi­cielles uti­li­sées pour la sur­veillance et la mesure des exi­gences. Ces appli­ca­tions logi­cielles doivent être vali­dées avant leur pre­mière uti­li­sa­tion et, lorsque appro­prié, après la modi­fi­ca­tion de ce logi­ciel ou de son application »

Aus­si, les fabri­cants ren­contrent encore des dif­fi­cul­tés avec cette thé­ma­tique, car cette exi­gence est sou­vent source de non-confor­mi­té lors des audits de cer­ti­fi­ca­tion ISO 13485 : 2016. En effet, bien sou­vent, tous les logi­ciels devant être vali­dés au sein des orga­nismes ne le sont pas. Ce fait, s’explique prin­ci­pa­le­ment par le manque d’information exis­tant sur cette exi­gence, la dif­fi­cul­té pour cer­taines entre­prises de recen­ser tous leurs logi­ciels, de com­prendre l’impact poten­tiel de ces logi­ciels, mais éga­le­ment par la chro­no­pha­gie poten­tielle de la mise en place de cette exigence.

Mais qu’entend exac­te­ment la norme par la ter­mi­no­lo­gie « vali­da­tion des appli­ca­tions logicielles » ?

Les appli­ca­tions logi­cielles repré­sentent les sys­tèmes informatisés/logiciels uti­li­sés en entreprise.

Le pro­ces­sus de vali­da­tion des appli­ca­tions logi­cielles selon l’ISO 13485 : 2016, revient à confir­mer que ces logi­ciels, pou­vant impac­ter la sécu­ri­té ou la qua­li­té des pro­duits de l’entreprise (ici les dis­po­si­tifs médi­caux), fonc­tionnent cor­rec­te­ment, au regard de leur fina­li­té d'utilisation.

D’après l’ISO 13485 elle repré­sente « toutes acti­vi­tés per­met­tant d’établir un niveau de confiance pour assu­rer que le logi­ciel est bien appro­prié à son uti­li­sa­tion pré­vue, est digne de confiance, mais éga­le­ment fiable ».

Ain­si, le but pre­mier de cette exi­gence est d’éviter les non-confor­mi­tés, en rédui­sant les risques d’incidents liés aux appli­ca­tions logi­cielles uti­li­sées dans le cadre du SMQ, qui peuvent impac­ter les DM.

L’objectif final du pro­ces­sus de vali­da­tion des appli­ca­tions logi­cielles consis­te­ra à avoir la capa­ci­té de four­nir des preuves docu­men­tées de la fia­bi­li­té, la sécu­ri­té et la per­for­mance des logi­ciels uti­li­sés dans les acti­vi­tés du SMQ.

Une fois qu’on a sai­si à quoi cor­res­pon­dait cette exi­gence, il faut déter­mi­ner comme l’appliquer. En effet, la norme 13495 : 2016 ne four­nit pas de métho­do­lo­gie pré­cise pour réa­li­ser cette vali­da­tion. Cepen­dant, des réfé­ren­tiels annexes four­nissent des indi­ca­tions pour réa­li­ser cor­rec­te­ment cette validation.

Par­mi ces réfé­ren­tiels, on retrouve prin­ci­pa­le­ment des réfé­ren­tiels inter­na­tio­naux tels que l’AAMI TIR36 : 2007 “Vali­da­tion of soft­ware for regu­la­ted pro­cesses”, le FDA Gui­dance “Gene­ral prin­ciples of soft­ware vali­da­tion”, mais éga­le­ment le docu­ment non nor­ma­tif ISO/TR 80002-2 “Logi­ciels de dis­po­si­tifs médi­caux - Par­tie 2 : Vali­da­tion des logi­ciels pour les sys­tèmes de qua­li­té des dis­po­si­tifs médi­caux”, docu­ment dis­po­nible uni­que­ment en anglais et prin­ci­pa­le­ment uti­li­sé dans le cadre de l’alternance pour mettre en place cette exigence.

Pour résu­mer, ces dif­fé­rents réfé­ren­tiels four­nissent plu­sieurs acti­vi­tés et outils, à exé­cu­ter au cours du cycle de vie du logi­ciel à vali­der, en fonc­tion de dif­fé­rents para­mètres. Ces acti­vi­tés et outils vont viser à garan­tir que le logi­ciel répond à ses exi­gences et à sa des­ti­na­tion, pour ain­si per­mettre de réduire les risques qui lui sont asso­ciés et à ren­for­cer la confiance dans le logi­ciel [19][28][29][30][31].

Méthodologie pour réaliser la validation des applications logicielles

Généralités

La norme ISO 13485 : 2016, n’apporte pas de métho­do­lo­gie pré­cise sur la réa­li­sa­tion de la vali­da­tion des appli­ca­tions logi­cielles, cepen­dant les rédac­teurs de celle-ci, sûre­ment conscients de la chro­no­pha­gie poten­tielle de cette tâche, ont émis un point impor­tant devant être mis en avant et même en pre­mier lieu de l’application de cette exi­gence : La pro­por­tion­na­li­té des efforts par rap­port au risque du logi­ciel, et donc l’adaptation de la quan­ti­té de tra­vail à four­nir en fonc­tion du risque logi­ciel.

En effet, la norme sou­tient que “L’approche spé­ci­fique et les acti­vi­tés asso­ciées à la vali­da­tion et la reva­li­da­tion du logi­ciel doivent être pro­por­tion­nées au risque asso­cié à son uti­li­sa­tion”, cette for­mule est fon­da­men­tale et doit être bien prise en compte par les fabri­cants de DM, car elle per­met­tra d’axer les efforts de façon ciblée et ain­si de ne pas dépen­ser du temps et de l’énergie dans la vali­da­tion de logi­ciel à risque faible.

Le guide ISO/TR 80002-2 parle éga­le­ment du recours à la « pen­sée cri­tique », tout au long du pro­ces­sus de vali­da­tion, qui fait direc­te­ment réfé­rence à la néces­si­té d’avoir une réflexion appro­fon­die quant à la néces­si­té de réa­li­ser telle ou telle acti­vi­té pour la vali­da­tion (moins le risque sera éle­vé, plus la rigueur et les efforts de vali­da­tion devront être faibles). Au-delà de l’analyse du risque du logi­ciel, la norme évoque le besoin d’analyser les risques de défaillances des pro­ces­sus qui vont être contrô­lés ou en par­tie contrô­lés par le logiciel.

Avant de débu­ter l’exposition de la métho­do­lo­gie mis en place au sein de ZOS IS pour vali­der ses appli­ca­tions logi­cielles (gran­de­ment basée sur l’ISO/TR 80002-2), le pro­ces­sus glo­bal de vali­da­tion uti­li­sé est repré­sen­té ci-des­sous (figure 6), c’est le fil direc­teur qui sera uti­li­sé pour décrire la méthode de validation :

Figure 6 Principales activités de validation en fonction des phases du cycle de vie du logiciel. Source : Figure 2 ISO/TR 80002-2

Comme le montre cette repré­sen­ta­tion issue de l’ISO/TR 80002-2, le cycle de vie d’une appli­ca­tion logi­cielle peut se décli­ner en trois phases :

• La phase de déve­lop­pe­ment : phase au cours de laquelle le besoin logi­ciel nait, et conduit à l’étude du besoin uti­li­sa­teur ain­si qu’à la concep­tion et la mise en œuvre du logi­ciel. C’est éga­le­ment la phase où l’on est cen­sé déter­mi­ner le besoin de validation
• La phase de main­te­nance : phase au cours de laquelle le logi­ciel est cen­sé avoir été vali­dé et est mis en ser­vice, et doit être régu­liè­re­ment sur­veillé au regard des modi­fi­ca­tions appor­tées ou des bugs pou­vant survenir
• Et la phase de retrait : phase au cours de laquelle le logi­ciel n’est plus uti­li­sé au sein de l’entreprise et doit donc être reti­ré des ser­veurs de l’entreprise

Au cours de ces phases, les besoins de vali­da­tion peuvent varier, et les acti­vi­tés et outils uti­li­sés pour la vali­da­tion vont éga­le­ment évoluer.

Une pro­cé­dure doit être réa­li­sée avant d’entreprendre la vali­da­tion des appli­ca­tions logi­cielles, cette pro­cé­dure doit défi­nir les dif­fé­rentes étapes de la vali­da­tion, mais éga­le­ment expli­ci­té l’effort de vali­da­tion par rap­port au risque en indi­quant, en fonc­tion du niveau de risque déter­mi­né, les acti­vi­tés et livrables requis.

Dans un pre­mier temps, l’action qui a été réa­li­sée pour débu­ter la vali­da­tion a été l’étude du guide ISO/TR 80002-2, son décryp­tage, sa com­pré­hen­sion et une réor­ga­ni­sa­tion des infor­ma­tions four­nis afin de conser­ver les élé­ments appa­rais­sant les plus per­ti­nents. Une fois l’étude de ce guide ter­mi­né et la cla­ri­fi­ca­tion des élé­ments appor­tés par ce der­nier, la démarche de vali­da­tion des appli­ca­tions logi­cielles, pré­sentes au sein de ZOS IS, a pu débuter.

Inventoriât des systèmes informatisés et détermination de l'applicabilité de la validation

Pré­am­bule : l’exigence de vali­da­tion des appli­ca­tions logi­cielles de l’ISO 13485 : 2016 exige que les « appli­ca­tions logi­cielles [soient] vali­dées avant leur pre­mière uti­li­sa­tion ». De ce fait, avant d’être uti­li­sé en entre­prise tout logi­ciel devant être vali­dé doit l’être, sous peine d’être non conforme à la norme. En réa­li­té, cela est très rare­ment pos­sible notam­ment en rai­son de l’apparition tar­dive de l’exigence. Par exemple, dans le cas des struc­tures comme ZOS IS, qui n’étaient pas à l’origine sou­mise à la règle­men­ta­tion des dis­po­si­tifs médi­caux, les logi­ciels uti­li­sés n’ont pas pu être vali­dés avant leur pre­mière utilisation.

En l’état, ce point n’est pas dra­ma­tique car l’avantage de ces logi­ciels est qu’il y a déjà, rétros­pec­ti­ve­ment, des infor­ma­tions sur son uti­li­sa­tion, sur des dys­fonc­tion­ne­ments ren­con­trés, des retours uti­li­sa­teurs, du per­son­nel for­mé etc qui vont être des don­nées d’entrée à la vali­da­tion et vont per­mettre géné­ra­le­ment d’écourter une par­tie du tra­vail à réaliser.

Cepen­dant, tout nou­veau logi­ciel inté­gré à l’entreprise doit être en temps nor­mal vali­dé, si l’exigence lui est applicable.

La pre­mière étape de la vali­da­tion logi­cielle est celle visant à iden­ti­fier l’ensemble des sys­tèmes infor­ma­ti­sés uti­li­sés au sein de l’entreprise, et donc à les inven­to­rier. Cette pre­mière étape est déci­sive et peut abou­tir à un lis­ting consé­quent. L’inventaire des SI doit être effec­tué avec une atten­tion par­ti­cu­lière et de façon pré­cau­tion­neuse en explo­rant et inter­ro­geant tous les ser­vices de l’entreprise. En effet, cer­tains logi­ciels peuvent avoir été mis en place par cer­tains ser­vices, pour faci­li­ter leur tra­vail, sans que la per­sonne en charge du lis­ting n’ait été tenue au cou­rant, et ces der­niers peuvent néces­si­ter d’être validés.

Au sein de ZOS IS, l’inventoriât a per­mis d’identifier 6 logi­ciels qui pour­raient entrer dans le champ d’application de la vali­da­tion des appli­ca­tions logicielles.

A noter que les SOUP (Logi­ciels tiers uti­li­sés, mais dont aucune preuve des per­for­mances est acces­sible), les dis­po­si­tifs médi­caux logi­ciels, et les logi­ciels uti­li­sés en tant que com­po­sant, par­tie ou acces­soire d’un DM ne sont pas concer­né par la pré­sente liste.

Une fois l’inventoriât réa­li­sé le fabri­cant doit déter­mi­ner si les logi­ciels iden­ti­fiés doivent réel­le­ment subir une vali­da­tion au sens que l’entend l’ISO 13485 : 2016.

Pour cela, le fabri­cant doit axer sa réflexion sur plu­sieurs élé­ments en se posant les ques­tions sui­vantes pour chaque logi­ciel listé :

1. Le logi­ciel auto­ma­tise-t-il ou exé­cute-t-il une acti­vi­té requise par les exi­gences régle­men­taires ? Pour cette ques­tion, il faut se concen­trer en par­ti­cu­lier sur les exi­gences rela­tives aux sys­tèmes de ges­tion de la qua­li­té des dis­po­si­tifs médi­caux et celles du règle­ment 2017/745.

Cela peut par exemple concer­ner des SI agis­sant au niveau de la cap­ture de signa­tures et/ou d'enregistrements élec­tro­niques, le main­tien de la tra­ça­bi­li­té des pro­duits, l'exécution et la cap­ture des résul­tats des tests, la main­te­nance des jour­naux de don­nées tels que les CAPA (actions cor­rec­tives et pré­ven­tives), les non-confor­mi­tés, les plaintes etc

• Une défaillance ou des défauts cachés du logi­ciel peuvent-ils affec­ter la sécu­ri­té ou la qua­li­té du SMQ ou du Dis­po­si­tif ?Il faut se deman­der si, lorsque le logi­ciel à une défaillance ou un dys­fonc­tion­ne­ment et ne peut plus être uti­li­sé comme habi­tuel­le­ment, cela peut conduire à un impact sur la qua­li­té et la sécu­ri­té du SMQ et du dis­po­si­tif. Cette ques­tion sera déve­lop­pée de façon appro­fon­die au tra­vers d’une ana­lyse de risque.

Par exemple : Si un logi­ciel d’étiquetage, dont la fonc­tion est d’imprimer direc­te­ment sur le condi­tion­ne­ment d’un DM, l’UDI, le numé­ro de lot, les dates (expi­ra­tion ect) ou encore la réfé­rence, subit une défaillance (erreur dans l’impression des infor­ma­tions pré­ci­tées), l’impact sur la sécu­ri­té du patient peut être désas­treux, en fonc­tion du DM uti­li­sé (par exemple dans le cas d’un cathé­ter pour lequel l’étiquetage contien­drait une erreur dans la taille de ce der­nier, le chi­rur­gien en lisant l’étiquetage impri­mer va se trom­per et prendre une mau­vaise taille, ce qui peut conduire à la mort du patient)

Le logi­ciel est-il uti­li­sé dans le SMQ ? Pour le sys­tème docu­men­taire du SMQ ?

Le logi­ciel est-il uti­li­sé en pro­duc­tion et dans le cadre des pres­ta­tions de ser­vices, d’une manière qui affecte la capa­ci­té du pro­duit à se confor­mer à des exi­gences spécifiées ? 

Dans le cas où au moins une des réponses est posi­tive à au moins une de ces ques­tions, le logi­ciel néces­site une vali­da­tion. Dans cer­tains cas, une jus­ti­fi­ca­tion peut être appor­tée pour exclure le logi­ciel de cette obli­ga­tion de validation. 

Les SI sui­vants entrent géné­ra­le­ment dans le cadre de la vali­da­tion (liste non exhaustive) :

• Logi­ciel sur équi­pe­ment de production 
• Logi­ciel sur équi­pe­ment de test 
• ERP (Enter­prise Res­source Plan­ning) => gros logi­ciel avec plu­sieurs modules et recou­pé dans plu­sieurs services
• Logi­ciel de ges­tion des docu­ments, et des enregistrements
• Logi­ciel de ges­tion des récla­ma­tions, des CAPA
• Logi­ciel de ges­tion du SAV (simi­laire à de la production) 
• Logi­ciel de ges­tion des équi­pe­ments, des dis­po­si­tifs de mesure 
• Logi­ciel de sui­vi de don­nées cliniques 
• Logi­ciel d’étiquetage (rentre dans les équi­pe­ments de production) 
• Logi­ciel de sui­vi des infrastructures 
• Feuilles Excel conte­nant des macros ou des for­mules com­plexes sur les acti­vi­tés précitées 

A contra­rio ce type de SI ne rentre pas dans le cadre de la vali­da­tion (liste non exhaustive) :

• Logi­ciel finan­cier ou admi­nis­tra­tif qui n’a pas d’impact sur le SMQ
• Micro­soft office (sauf macro), la FDA a décla­rée qu’on consi­dé­rait qu’il y avait des mil­lions d’utilisateurs depuis des mil­liers d’années et que donc c’était validé 
• Logi­ciel de mai­ling, sauf si dans les mai­lings il y a des enre­gis­tre­ments qua­li­té (dans le cas où l’on à para­mé­tré le mail pour faire des choses concer­nant la qualité)
• Les sys­tèmes d’exploitation  

Dans le cas de ZOS IS, trois SI lis­tés ont été iden­ti­fiés com­ment devant être sou­mis à une vali­da­tion, car ils inter­viennent à la fois dans la confor­mi­té du pro­duit, dans la tra­ça­bi­li­té, et dans la ges­tion du sys­tème docu­men­taire. Un dos­sier de vali­da­tion a alors été créé pour cha­cun de ces logiciels.

Définition des systèmes informatisés et des processus associés

Lorsque la déter­mi­na­tion de l’ensemble des SI devant être sou­mis à la vali­da­tion selon l’ISO 13485 : 2016 a été réa­li­sée, l’étape de défi­ni­tion rentre en jeu.

Cette deuxième étape doit éga­le­ment être faite de façon rigou­reuse, elle consiste à défi­nir de façon rela­ti­ve­ment pré­cise le logiciel.

Pour défi­nir cor­rec­te­ment le logi­ciel, plu­sieurs élé­ments doivent être déter­mi­nés en col­la­bo­ra­tion directe avec les uti­li­sa­teurs du logiciel :

• Le(s) fonctionnalité(s) du logiciel 
• Le(s) exigence(s) des uti­li­sa­teurs (spé­ci­fi­ca­tion des besoins uti­li­sa­teurs), l’utilisation du logi­ciel et le contexte d’utilisation 
  • Les spé­ci­fi­ca­tions des besoins uti­li­sa­teurs sont impor­tantes et doivent être défi­nies de la façon la plus exhaus­tive pos­sible avec les uti­li­sa­teurs directs du logi­ciel. Cette spé­ci­fi­ca­tion inter­vien­dra par la suite dans l’analyse des risques.
  • L’utilisation du logi­ciel doit être cor­rec­te­ment iden­ti­fiée, car le logi­ciel est vali­dé sur la base de son uti­li­sa­tion pré­vue, et donc si cette uti­li­sa­tion est ame­née à être modi­fiée au cours du temps, cela pour­ra avoir un impact sur l’état vali­dé du logiciel
  • Le contexte d’utilisation aide à l’identification de l’utilisation logi­ciel et peut pas­ser par la réponse aux ques­tions suivantes :

• Les spé­ci­fi­ca­tions de la concep­tion fonc­tion­nelle : ces spé­ci­fi­ca­tions sont à défi­nir essen­tiel­le­ment dans le cas où le logi­ciel est conçu tota­le­ment, ou en par­tie, en interne de l’organisme
• Les élé­ments de sor­tie atten­dus du logi­ciel peuvent éga­le­ment être docu­men­tés (par exemple : le logi­ciel doit four­nir des enre­gis­tre­ments de confor­mi­té du pro­duit, des résul­tats de cal­cul inter­ve­nant dans la confor­mi­té du pro­duit ou encore le résul­tat des indi­ca­teurs qua­li­tés de l’entreprise) 

L’ensemble de ces élé­ments vont ser­vir d’éléments d’entrée pour réa­li­ser l’analyse des risques et ain­si pou­voir défi­nir l’effort de vali­da­tion à appli­quer pour chaque SI. Ils doivent être for­ma­li­sés et donc documentés.

Éga­le­ment, les pro­ces­sus contrô­lés ou en par­tie contrô­lés par le logi­ciel devront être définis.

La défi­ni­tion d’un seul logi­ciel a pour l’instant pu être docu­men­tée au sein de la struc­ture, mais ce der­nier est à amé­lio­rer en incluant tous les uti­li­sa­teurs directs.

Analyse des risques (de défaillances)

Cette troi­sième étape est cru­ciale et doit être l’un des élé­ments mini­mums de la vali­da­tion des appli­ca­tions logi­cielles à réa­li­ser, avant un audit de cer­ti­fi­ca­tion ISO 13485 : 2016, si l’on sou­haite évi­ter des non-confor­mi­tés sur cette exigence.

En effet, l’analyse de risque est obli­ga­toire pour tout sys­tème infor­ma­ti­sé devant être sou­mis à vali­da­tion. Il est donc fon­da­men­tal que l’entreprise ait entre­pris une démarche d’analyse des risques pour l’ensemble des logi­ciels à vali­der, lui per­met­tant ain­si de prio­ri­ser la vali­da­tion de ses logi­ciels. Ain­si, dans le cas où les logi­ciels à vali­der n’auraient pas pu l’être avant l’audit de cer­ti­fi­ca­tion, l’entreprise pour­ra jus­ti­fier cela en décla­rant que, de par la prio­ri­sa­tion des logi­ciels à vali­der, elle s’est concen­trée en pre­mier lieu sur ceux avec le risque le plus éle­vé (sous-enten­du que les logi­ciels à haut risque sont vali­dés lors de l’audit).

Pour réa­li­ser son ana­lyse des risques l’entreprise peut réuti­li­ser sa pro­cé­dure de ges­tion des risques (nor­ma­le­ment pré­sente dans toute entre­prise de DM) ou elle peut se baser sur d’autres méthodes d’analyse, telles que l’AMDEC (Ana­lyse des modes de Défaillance, de leurs Effets et de leur Criticité).

L’AMDEC est une méthode de ges­tion des risques per­met­tant d’évaluer les modes de défaillances poten­tielles d’un pro­ces­sus, d’un pro­duit, ou d’une organisation. 

L’analyse des risques réa­li­sée pour chaque logi­cielle est effec­tuée pour éva­luer les consé­quences d’une défaillance logi­cielle sur : 

• la confor­mi­té du produit
• le patient 
• le sys­tème mana­ge­ment de la qualité 
• la régle­men­ta­tion 
• la qua­li­té des docu­ments et des enregistrements 

Elle peut ain­si être réa­li­sée en recher­chant les séquences d’événements sui­vants (sans s’y limiter) : 

• Pour les logi­ciels uti­li­sés sur ou avec des équi­pe­ments en production : 
  • La consé­quence sur l’équipement qu’il contrôle ou supporte, 
  • La consé­quence sur la confor­mi­té du produit, 
  • La consé­quence sur le patient 
• Pour les logi­ciels uti­li­sés pour l’entretien : 
  • La consé­quence sur le ser­vice qu’il contrôle ou supporte, 
  • La consé­quence sur la confor­mi­té du pro­duit ou du service, 
  • La consé­quence sur le patient, 
• Pour les logi­ciels uti­li­sés pour trai­ter des don­nées de qua­li­té ou réglementaires : 
  • La consé­quence sur la qua­li­té des docu­ments ou des enregistrements, 
  • La consé­quence sur la confor­mi­té du produit, 
  • La consé­quence sur le patient, 
• Pour tous les logiciels : 
  • La consé­quence d’une faille de sécu­ri­té ou d’une attaque, 
  • La consé­quence sur la qua­li­té des docu­ments ou des enregistrements, 
  • La consé­quence sur la confor­mi­té du produit, 
  • La consé­quence sur le patient, 

Le choix de la méthode de réa­li­sa­tion de l’analyse des risques au sein de ZOS IS s’est basé sur la méthode AMDEC, la pro­cé­dure de ges­tion de risque n’a pas été uti­li­sée car cette der­nière était uni­que­ment adap­tée à l’analyse des risques liée au pro­duit de l’entreprise (le logi­ciel I-GEIA).

L’analyse des risques de défaillance des pro­ces­sus contrô­lés ou en par­tie contrô­lés par le logi­ciel est réalisée.

Cette méthode est par­ti­cu­liè­re­ment adap­tée car elle prend direc­te­ment en compte l’aspect du risque lié aux défaillances pos­sibles. Elle a été réa­li­sée pour le logi­ciel ayant été défi­nie comme évo­qué dans la par­tie pré­cé­dente et a abou­ti à la conclu­sion que le logi­ciel avait un niveau de risque mineur.

Etablissement d'un plan de validation

C’est lors de cette étape que la for­mule de la norme 13485 : 2016 « L’approche spé­ci­fique et les acti­vi­tés asso­ciées à la vali­da­tion et la reva­li­da­tion du logi­ciel doivent être pro­por­tion­nées au risque asso­cié à son uti­li­sa­tion » inter­vient et prend tout son sens.

Lorsque l’analyse des risques a été réa­li­sée et les niveaux de risques des dif­fé­rents logi­ciels a vali­dé ont été défi­nis et a per­mis de prio­ri­ser les logi­ciels, il faut effec­tuer la pla­ni­fi­ca­tion de la vali­da­tion au tra­vers de la réa­li­sa­tion d’un plan de vali­da­tion (éga­le­ment appe­lé par­fois « Pro­to­cole de Vali­da­tion » ou « Vali­da­tion Mas­ter Plan » pour « Plan Maitre de Validation »).

Le plan de vali­da­tion est le docu­ment qui per­met­tra d’établir les acti­vi­tés et outils choi­sis pour pour­suivre la vali­da­tion des sys­tèmes infor­ma­ti­sés, il décrit éga­le­ment les tâches de véri­fi­ca­tions appropriées. 

Aus­si, plus le plan fera inter­ve­nir des outils et acti­vi­tés, plus le niveau d’effort pour la vali­da­tion et la rigueur exi­gé pour la docu­men­ta­tion asso­ciée sera impor­tant. Et cette déter­mi­na­tion se base prin­ci­pa­le­ment sur les ana­lyses des risques de défaillance réa­li­sée pour les SI, mais le guide ISO/TR 80002-2 indique éga­le­ment que l’analyse des risques des défaillances du pro­ces­sus asso­cié vien­dra condi­tion­ner la rigueur pour la documentation.

Cette acti­vi­té de pla­ni­fi­ca­tion abou­tit à un plan docu­men­té qui décrit et fournit : 

• Les res­pon­sa­bi­li­tés (qui est en charge de réa­li­ser quoi)
• Les choix effec­tués en termes d’activités/d’outils : c’est-à-dire les déci­sions, les choix pris d’activité et d’outil (une liste non exhaus­tive des activités/outils est dis­po­nible dans la 80002-2)
• Les rai­sons des choix effec­tués : les fac­teurs de déci­sion ayant abou­ti à ces choix d’outil et d’activité (basé sur le risque) 
• Des preuves objec­tives de l'application de la pen­sée cri­tique au pro­ces­sus de pla­ni­fi­ca­tion de la validation. 
• Les docu­ments de sor­tie attendus

Les acti­vi­tés prin­ci­pales retrou­vées pour vali­der les logi­ciels sont les suivantes :

La Qua­li­fi­ca­tion de Concep­tion (QC) :

Elle concerne essen­tiel­le­ment les logi­ciels qui ont été déve­lop­pés tota­le­ment, ou en par­ties, en interne de l’entreprise (peut être adap­té à des logi­ciels ache­té et hau­te­ment confi­gu­rable, dans ce cas l’éditeur doit pou­voir four­nir la docu­men­ta­tion néces­saire à cette qualification).

Pour les logi­ciels conçus en interne, une pro­cé­dure de concep­tion doit nor­ma­le­ment exis­ter, et les docu­ments sui­vants réa­li­sés et ajou­tés à la QC :

• Des revues de concep­tion (véri­fi­ca­tion et validation) 
• Les spé­ci­fi­ca­tions du logiciel 
• Des tests du déve­lop­pe­ment logiciel

En fonc­tion du risque du logi­ciel les docu­ments sui­vants pour­ront ali­men­ter la QC :

La Qua­li­fi­ca­tion d’Installation (QI) :

Elle vise à s’assurer que le sys­tème infor­ma­ti­sé est cor­rec­te­ment ins­tal­lé et dans le bon envi­ron­ne­ment. Elle concerne essen­tiel­le­ment les logi­ciels néces­si­tant une ins­tal­la­tion spécifique.

Cette qua­li­fi­ca­tion per­met de tes­ter l’installation du soft­ware mais éga­le­ment du hard­ware (réseau, accès, connec­tions). En effet, il peut arri­ver que des pré­re­quis tech­niques (par exemple en termes de débit, de réseau etc) à l’installation d’un logi­ciel soient néces­saires, il faut donc déter­mi­ner si l’infrastructure de l’entreprise répond bien à ces prérequis.

Lors de cette qua­li­fi­ca­tion, les élé­ments sui­vants pour­ront éga­le­ment être vérifiés :

• Si des contrats de main­te­nance existent avec l’éditeur et auquel cas si une main­te­nance effec­tive existe.
• Véri­fier que les para­mé­trages sont bons et que tout est cor­rec­te­ment paramétré 
• Véri­fier que toute la docu­men­ta­tion utile du logi­ciel (notice d’utilisation etc) est pré­sente et à jour (conforme à la ver­sion utilisée…) 
• Véri­fier que les for­ma­tions du per­son­nel sont à jour (il est per­ti­nent d’avoir un uti­li­sa­teur clé qui sera le réfé­rent d’un SI) 
• Tes­ter la migra­tion des don­nées, elle doit être docu­men­tée pour avoir la preuve qu’elle a été faite correctement 

Il est aus­si impor­tant que l’entreprise rédige des docu­ments qui déroulent le fonc­tion­ne­ment du logi­ciel (des ins­truc­tions du logi­ciel, elles ne doivent pas être for­cé­ment très détaillées, mais conte­nir au moins les bases d’utilisation et les ins­truc­tions des fonc­tion­na­li­tés cri­tiques pour expli­quer com­ment se ser­vir du logiciel) 

Aus­si, en fonc­tion du risque du logi­ciel les docu­ments sui­vants pour­ront ali­men­ter la QI :

La Qua­li­fi­ca­tion Opé­ra­tion­nelle (QO) :

Elle a pour but d’assurer que chaque fonc­tion du sys­tème infor­ma­ti­sé fonc­tionne comme pré­vu et ain­si de véri­fier que le logi­ciel fonc­tionne selon l’emploi pré­vu et les besoins utilisateur. 

Il faut donc se poser la ques­tion « Est-ce que le logi­ciel fonc­tionne spé­ci­fi­que­ment à ceux que l’on souhaite »

Pour réa­li­ser cette vali­da­tion, il est pos­sible de se baser sur la QC de l’éditeur, si ce der­nier a four­ni un cer­tain nombre de tests, qui devront être réef­fec­tués (car l’environnement de l’entreprise peut être dif­fé­rent de l’environnement ini­tial de test : le nombre de connexion, le type d’utilisateur etc.).

Il faut éga­le­ment tes­ter le fonc­tion­ne­ment du logi­ciel dans un mode dégra­dé et tes­ter prio­ri­tai­re­ment les élé­ments à risque : Par exemple, si un champ à risque existe dans lequel il faut rem­plir un numé­ro de lot et qu’il est implé­men­té pour recueillir 14 digit, il faut regar­der ce qu’il se passe lorsque l’on va mettre un nombre de digit dif­fé­rent à 14 (16 ou 9 par exemple) pour voir com­ment le logi­ciel réagis (déclen­che­ment d’un signal d’erreur ou d’alertes ? ou le logi­ciel ne réagit pas et dans ce cas il y a un pro­blème et une action doit être entreprise).

Il faut tes­ter que les fonc­tions de sécu­ri­té marchent (alerte qui se déclenche, ou qui doivent appa­raitre), tes­ter les sauvegardes/restauration (si on fait exprès de perdre les don­nées, est-ce qu’on les récu­père bien ?), les fonc­tions de main­te­nance (marchent-elles ? par exemple si pos­si­bi­li­té d’avoir accès à dis­tance au logi­ciel pour dépan­ner. Est-ce que cet accès fonctionne ?) 

A noter que les pro­to­coles de QO ne sont pas for­cé­ment tes­tés par une seule per­sonne mais par dif­fé­rentes per­sonnes com­pé­tentes (les uti­li­sa­teurs), et une per­sonne doit être en charge de récu­pé­rer et com­pi­ler tous les docu­ments. En fonc­tion du risque du logi­ciel les docu­ments sui­vants pour­ront aus­si ali­men­ter la QO :

La Qua­li­fi­ca­tion de Per­for­mance (QP) :

Elle vise à garan­tir que le sys­tème infor­ma­ti­sé fonc­tionne comme pré­vu dans son envi­ron­ne­ment cible et avec les uti­li­sa­teurs cible. Elle per­met donc de qua­li­fier le logi­ciel dans son envi­ron­ne­ment réel, dit « de rou­tine » (soit on la réa­lise sur la vraie pla­te­forme, soit sur une pla­te­forme de test, mais dans un contexte de rou­tine réel).

Avec la QP, on va beau­coup plus loin, elle est plu­tôt exi­gée pour des logi­ciels à haut risque car la QI et la QO sécu­rise déjà beau­coup le logi­ciel, puisque nor­ma­le­ment en les réa­li­sant il est démon­tré qu’il n’y a pas de gros bugs, que tout est bien ins­tal­lé, et que tout le monde est cor­rec­te­ment formé.

Cepen­dant, la QP per­met de faire des scé­na­rios d’utilisation com­plets, ce qui est beau­coup plus lourd en termes de tra­vail à four­nir, mais per­met de voir les per­for­mances du logiciel.

Pour réa­li­ser les tests, il faut :

• Des tes­teurs indé­pen­dants, celui qui déve­loppe ne peut pas être celui qui teste. Il faut une stra­té­gie pour savoir qui va tes­ter car c’est une acti­vi­té très chro­no­phage => per­sonne dédiée (spé­ci­fi­que­ment embau­chée pour réa­li­ser les tests) ou per­sonne interne (effec­tuant déjà d’autres acti­vi­tés), cette der­nière option peut s’avérer com­pli­qué dans le cas où la charge de tra­vail est déjà impor­tante. Mais en TPE comme chez ZOS IS, il est com­pli­qué d’embauché, il faut donc essayer de réduire le nombre de logi­ciels à vali­der et avoir réel­le­ment une stra­té­gie décrois­sante en fonc­tion du risque.
• Avoir un envi­ron­ne­ment repré­sen­ta­tif (don­nées réa­listes, mais sans risque de cor­rompre les don­nées de l’entreprise), néces­si­té de dupli­quer l’environnement  
• For­mer les tes­teurs à la docu­men­ta­tion, il faut docu­men­ter les tests 

Dans le cas où des pro­blèmes, des bugs ou encore appe­lé des dévia­tions sur­vien­draient au cours des tests, les actions sui­vantes devraient être menées : 

• Enre­gis­trer les dévia­tions, faire une ana­lyse de cause, et défi­nir une action cor­rec­tive si néces­saire (il serait per­ti­nent d’expliquer dans la pro­cé­dure de vali­da­tion ce qui serait un pro­blème mineur, pour lequel on ne fait pas d’action, et ce qui sera un pro­blème cri­tique où une action directe doit être menée) 
• Se poser la ques­tion si on refait des tests après la mise en place des actions (tests complémentaires) 
• Si on fait des tests de régres­sion, si l’on refait toute la QO, toute la vali­da­tion, ou juste quelques tests dits de « débug » 

A noter qu’il existe dif­fé­rents niveaux de cri­ti­ci­té d’un bug (par exemple : mineur, signi­fi­ca­tive, majeur, cri­tique et catas­tro­phique). Ce qui engendre qu’il y a pos­si­bi­li­té de décla­rer par exemple que tous les bugs mineurs n’ont pas besoin d’être cor­ri­gé (mais cela doit être défi­ni dans un document). 

En fonc­tion du risque du logi­ciel les docu­ments sui­vants pour­ront ali­men­ter la QP :

Exécution du plan de validation et rédaction du rapport de validation

Une fois effec­tué, le plan de vali­da­tion doit être appli­qué, les acti­vi­tés réa­li­sées et les outils utilisés.

La réa­li­sa­tion du plan de vali­da­tion va abou­tir à plu­sieurs résul­tats qui devront être recen­sés et étudiés.

C’est l’étape 6 de rédac­tion du rap­port de validation.

En plus de com­pi­ler tous les résul­tats de don­nées, ce rap­port devra expli­ci­te­ment conclure sur l’état vali­dé du logi­ciel, et le fait donc qu’il puisse être utilisé.

Dans le cas où des résul­tats de test ne cor­res­pon­dant pas aux atten­dus auraient été obte­nus, plu­sieurs pos­si­bi­li­tés s’offrent telles que :

• L’ouverture de non-confor­mi­té et la réa­li­sa­tion des actions pour se rendre conforme
• L’acceptation du logi­ciel en l’état, dans le cas où le résul­tat non atten­du est jus­ti­fié ou argumenté

Il est très impor­tant de bien conclure à l’issue de ce rap­port et de sta­tué sur le fait que le logi­ciel peut être uti­li­sé en toute sécu­ri­té ou que les risques asso­ciés à ce logi­ciel sont mai­tri­sés. Bien sou­vent les entre­prises oublient cette conclu­sion dans leur rap­port de validation. 

En résu­mé, le rap­port de vali­da­tion final doit por­ter sur les points suivants : 

• Un résu­mé glo­bal du pro­jet de validation 
• Une liste de tous les livrables générés
• Tout écart par rap­port à la pro­cé­dure de vali­da­tion des appli­ca­tions logicielles 
• Une conclu­sion indi­quant si le sys­tème infor­ma­ti­sé est vali­dé ou non 

A noter : un rap­port de qua­li­fi­ca­tion peut être réa­li­sé en amont du rap­port final de vali­da­tion. Ce rap­port devra syn­thé­ti­ser l'ensemble des phases de qua­li­fi­ca­tions, avec leurs résul­tats, les bugs ou dévia­tions appa­rues, les actions cor­rec­tives ou pré­ven­tives menées et les modi­fi­ca­tions si appli­cables. Il pour­ra éga­le­ment inclure une conclu­sion préa­lable par rap­port à la qualification.

Surveillance des changements et revalidation

Une fois les logi­ciels vali­dés, la vali­da­tion des appli­ca­tions logi­cielles ne s’arrête pas là.

La 7^ème et der­nière étape de la vali­da­tion consiste à s’assurer que les logi­ciels vali­dés, res­tent dans un état vali­dé tout au long de leur uti­li­sa­tion, en s’adaptant, en gérant et en contrô­lant divers types de changements.

Dif­fé­rentes rai­sons existent pour les­quelles le logi­ciel chan­ge­rait après sa mise en ser­vice. Par­mi les types de modi­fi­ca­tions de main­te­nance les plus cou­rants, on peut retrouver : 

• Les modi­fi­ca­tions de main­te­nance cor­rec­tive (uti­li­sées pour cor­ri­ger les erreurs et les défauts du logiciel) 
• Les modi­fi­ca­tions de main­te­nance pré­ven­tive (uti­li­sées pour amé­lio­rer les per­for­mances, la main­te­na­bi­li­té ou d'autres attri­buts du logiciel) 
• La main­te­nance adap­ta­tive effec­tuée pour mettre à jour l'environnement opé­ra­tion­nel du logi­ciel (par exemple, modi­fi­ca­tions du sys­tème d'exploitation, du maté­riel du sys­tème ou d'autres appli­ca­tions avec les­quelles le logi­ciel s'interface). 

Toute modi­fi­ca­tion appor­tée à un SI vali­dé doit être réa­li­sée de manière contrô­lée confor­mé­ment à une pro­cé­dure (la pro­cé­dure « contrôle des modi­fi­ca­tions » doit être défi­nie dans une entre­prise de DM).

Ain­si, il est néces­saire de défi­nir un inter­valle mini­mum au cours duquel, les logi­ciels vali­dés seront (re) ana­ly­sés, afin de déter­mi­ner si des chan­ge­ments ont pu conduire à une modi­fi­ca­tion de leur état vali­dé (inter­valle à défi­nir dans la pro­cé­dure de validation). 

Lors d’une modi­fi­ca­tion logi­cielle, une ana­lyse d’impact doit être réa­li­sée quant à son effet sur : 

• L'utilisation pré­vue 
• Le risque de défaillance 
• L’introduction de nou­veaux risques 
• Les mesures de contrôle des risques existantes 
• Toute fonc­tion­na­li­té du logi­ciel lui-même 

Les modi­fi­ca­tions pou­vant abou­tir à la néces­si­té d’une reva­li­da­tion peuvent être : 

• Modi­fi­ca­tion du pro­ces­sus dans lequel le logi­ciel est utilisé 
  • Lorsque le pro­ces­sus entiè­re­ment ou par­tiel­le­ment contrô­lé par le logi­ciel change, une ana­lyse d'impact doit être réa­li­sé (impact sur les mesures de contrôle des risques, l’utilisation prévue...) 
• Chan­ge­ment de sa configuration 
• Chan­ge­ment de son niveau de risque 
• Chan­ge­ment dans l’utilisation pré­vue du logiciel 
  • S'il y a un chan­ge­ment signi­fi­ca­tif dans l'utilisation pré­vue du logi­ciel, il doit être vali­dé pour la nou­velle uti­li­sa­tion pré­vue ou la nou­velle uti­li­sa­tion doit ces­ser (dans ce cas, une éva­lua­tion des risques est néces­saire pour s'assurer qu'aucun risque n'a été intro­duit pen­dant la période d'utilisation non autorisée) 

Un plan de main­te­nance doit être réa­li­sé pour défi­nir quelles sont les acti­vi­tés opé­ra­tion­nelles réa­li­sables sans que la vali­da­tion du logi­ciel soit affec­tée et quelles modi­fi­ca­tions néces­sitent des efforts de vali­da­tion et donc une revalidation. 

Chaque opé­ra­teur du logi­ciel doit être for­mé à recon­naitre la dif­fé­rence entre les acti­vi­tés opé­ra­tion­nelles nor­males et tout chan­ge­ment néces­si­tant poten­tiel­le­ment une (re)validation. 

Il peut être éga­le­ment per­ti­nent que le “Plan de vali­da­tion”, indique les élé­ments condui­sant à une reva­li­da­tion d’un sys­tème infor­ma­ti­sé et décrit les actions et acti­vi­tés néces­saires à cette revalidation. 

Une fois cette der­nière étape implé­men­tée, la vali­da­tion des appli­ca­tions logi­cielles au sein d’une entre­prise est en théo­rie conforme.

Un résu­mé glo­bal sous forme de logi­gramme de la démarche de vali­da­tion des appli­ca­tions logi­cielles est dis­po­nible en annexe 2 [19][28][29][30][31].

Chapitre 4 : Bilan personnel de mon expérience d'apprentie

Evolution personnelle au sein de ZOS IS

Lors de l’intégration du Mas­ter Ingé­nie­rie de la San­té par­cours Dis­po­si­tifs Médi­caux et Affaires Règle­men­taires, mon pro­jet pro­fes­sion­nel s’est rapi­de­ment tour­né vers le métier de Char­gé des Affaires Régle­men­taires des dis­po­si­tifs médicaux.

Le métier de Char­gé des Affaires Règle­men­taires des DM englobe toutes les acti­vi­tés per­met­tant de garan­tir que les dis­po­si­tifs médi­caux sont, tout au long de leur cycle de vie, conforment à la règle­men­ta­tion qui leur est applicable.

Le 30 août 2021, j’intégrais l’entreprise ZOS Infor­ma­tion Sys­tem, non pas en tant qu’apprentie Char­gée des Affaires Règle­men­taires des DM, mais en tant qu’apprentie Char­gée des Affaires Régle­men­taires et de la Qua­li­té des DM.

Le métier de Char­gé Affaires Règle­men­taires et Qua­li­té des DM, regroupe l’aspect règle­men­taire, com­pre­nant les élé­ments cités pré­cé­dem­ment et l’aspect qua­li­té englo­bant les acti­vi­tés per­met­tant d’assurer le bon fonc­tion­ne­ment et le bon sui­vi du sys­tème de mana­ge­ment de la qualité.

Ces deux aspects dans le sec­teur des DM sont très étroi­te­ment liés et peuvent se confondre contrai­re­ment à d’autres sec­teurs ou les deux aspects se dif­fé­ren­cient de façon beau­coup plus mar­quée (dans le sec­teur phar­ma­ceu­tique par exemple). C’est pour­quoi, l’ambivalence du poste ne m’a pas blo­qué pour sai­sir cette oppor­tu­ni­té d’alternance.

L’alternance était pour moi la moda­li­té d’étude la plus per­ti­nente, car elle me per­met­tait de mettre direc­te­ment en appli­ca­tion les savoirs qui m’ont été déli­vrés lors de mes années d’étude, et ain­si de mieux les inté­grer et d’acquérir plus faci­le­ment et plus rapi­de­ment les savoir-faire associés.

Aus­si, mon début d’alternance n’a pas été sans dif­fi­cul­té, en effet plu­sieurs fac­teurs sont entrés en jeu dans cette com­plexi­té, tels que :

• La taille de l’entreprise : ZOS IS est une TPE, de ce fait le nombre de sala­riés est res­treint, et comme dans de nom­breuses TPE les fron­tières en termes de tra­vail ne sont pas tou­jours défi­nies, ce qui conduit très sou­vent à por­ter plu­sieurs cas­quettes. Ain­si, le ser­vice qua­li­té et affaires règle­men­taires, à mon arri­vé, ne comp­tait qu’une per­sonne, la Res­pon­sable qua­li­té et affaires régle­men­taires, ce qui pou­vait repré­sen­ter un frein pour une pro­gres­sion effi­ciente, compte tenu de la quan­ti­té de tra­vail et de l’ensemble des démarches devant être réa­li­sée pour obte­nir le mar­quage CE dans les délais impartis.
• L’expérience de la Res­pon­sable qua­li­té et affaires régle­men­taires : Bien que cette der­nière ait pu suivre une for­ma­tion cer­ti­fiante, la res­pon­sable QAR n’avait pas encore acquis un recul suf­fi­sam­ment solide en termes d’expérience pro­fes­sion­nel dans le domaine, lui per­met­tant d’avoir des connais­sances sur les attentes (notam­ment des orga­nismes noti­fiés) mais éga­le­ment d’avoir un regard plus construit et clair sur la ligne direc­trice à suivre.

Ain­si, mal­gré un démar­rage dif­fi­cile, l’autonomie et la diver­si­té des tâches confiées, m’ont per­mis d’avoir une réelle vision glo­bale sur la grande majo­ri­té des acti­vi­tés du char­gé ARQ et ain­si de tra­vailler sur dif­fé­rents aspects du domaine, me per­met­tant d’acquérir et d’approfondir rapi­de­ment diverses com­pé­tences. Ce fut donc une alter­nance qui s’est révé­lée très chal­len­geante et formatrice.

J’ai en effet pu, lors de cette expé­rience, appro­fon­dir l’étude de plu­sieurs réfé­ren­tiels incon­tour­nable dans le sec­teur du DM, ce qui me confère à l’heure actuelle une mai­trise impor­tante de plu­sieurs de ces référentiels :

• Le règle­ment 2017/745, texte légis­la­tif qui indique les dif­fé­rentes exi­gences per­met­tant de mettre sur le mar­ché euro­péen un dis­po­si­tif médi­cal, et les diverses obli­ga­tions qui incombent aux dif­fé­rents acteurs de l’industrie du DM
• L’ISO 13485 : 2016, por­tant sur la mise en place d’un sys­tème de mana­ge­ment de la qua­li­té chez les indus­triels du DM
• L’ISO 14971 : 2019, sur l’application de la ges­tion des risques aux dis­po­si­tifs médi­caux, et le guide asso­cié FD CEN ISO/TR 24917 qui donne des recom­man­da­tions sur l’application de l’ISO 14971
• La NF EN 62366-1 : 2015, sur l’application de l’ingénierie de l’aptitude à l’utilisation aux dis­po­si­tifs médi­caux, pro­ces­sus per­met­tant d’évaluer et de réduire les risques asso­ciés à une uti­li­sa­tion nor­male d’un DM
• La NF EN 62304 : 2006, qui vient défi­nir les exi­gences en ce qui concerne le cycle de vie des dis­po­si­tifs médi­caux logiciels
• L’ISO/TR 80002-2 : 2017, qui est un guide por­tant sur la vali­da­tion des appli­ca­tions logi­cielles du SMQ

Grâce au guide ISO/TR 80002-2 j’ai pu apprendre à mai­tri­ser plu­sieurs aspects de l’exigence de vali­da­tion des appli­ca­tions logicielles.

J’ai éga­le­ment pu par­ti­ci­per à la ges­tion des risques, et ain­si mieux mai­tri­ser les livrables asso­ciés et déve­lop­per ma réflexion sur l’Identification et l’analyse des risques, leur esti­ma­tion, leur éva­lua­tion et leur mai­trise. Mon appren­tis­sage sur la NF EN 62366 m’a éga­le­ment appor­té des élé­ments sur la ges­tion des risques, car cette der­nière déve­loppe des élé­ments per­met­tant de pré­ve­nir les risques dus aux erreurs d’utilisation d’un DM. J’ai ain­si pu débu­ter la rédac­tion du dos­sier d’ingénierie d’aptitude à l’utilisation du DM logi­ciel I-GEIA, et notam­ment les par­ties concer­nant la spé­ci­fi­ca­tion d’utilisation d’I-GEIA (par­tie très étroi­te­ment liée à cer­tains atten­dus du dos­sier tech­nique du DM).

J’ai pu déve­lop­per mes capa­ci­tés rédac­tion­nelles, mais éga­le­ment de syn­thèse, en appre­nant la rédac­tion des pro­cé­dures, des fiches pro­ces­sus et de divers autres documents.

Enfin, cette auto­no­mie m’a appris à prendre des ini­tia­tives, à être force de pro­po­si­tion, mais éga­le­ment à réus­sir à com­mu­ni­quer de façon adap­tée et diplo­mate avec l’ensemble des acteurs impli­qués dans la démarche qua­li­té. J’ai ain­si pu par­ti­ci­per à la sen­si­bi­li­sa­tion du per­son­nel à la qua­li­té au tra­vers de dif­fé­rentes pré­sen­ta­tions. Pour résu­mer mon évo­lu­tion en termes de com­pé­tence, j’ai réa­li­sé un gra­phique radar (figure 7), qui illustre mon regard per­son­nel sur ma pro­gres­sion glo­bale au tra­vers de cette alternance :

Figure 7 Graphique de l'évolution de mes compétences à la suite de mon alternance. Source : Auteure

Mon bilan glo­bal de cette pre­mière réelle expé­rience dans mon domaine a donc été posi­tif et très enrichissant.

Il me reste encore à déve­lop­per plus en pro­fon­deur cer­tains élé­ments, notam­ment concer­nant la ges­tion de risque, l’alimentation du dos­sier tech­nique, mais éga­le­ment la mise en place de la sur­veillance après-com­mer­cia­li­sa­tion et la réa­li­sa­tion de l’évaluation cli­nique, élé­ment fon­da­men­tal de la nou­velle régle­men­ta­tion des DM.

Relation entre ma formation théorique et mon expérience professionnelle

La for­ma­tion à l’UTC est très per­ti­nente dans le domaine de la qua­li­té et des affaires régle­men­taires. En effet, cette der­nière nous offre une vision glo­bale et solide sur les métiers du domaine au tra­vers des divers cours réa­li­sés. La place impor­tante de la qua­li­té dans la for­ma­tion est très per­ti­nente, car en tra­vaillant dans le domaine, on se rend très vite compte que la qua­li­té est cen­trale dans l’ensemble des acti­vi­tés effectuées.

Aus­si, les nom­breux ensei­gne­ments dis­pen­sés par des inter­ve­nants du monde pro­fes­sion­nel ont été essen­tiels dans notre appro­pria­tion rapide du métier et de ces attendus.

Enfin, il serait inté­res­sant que la for­ma­tion puisse nous offrir plus d’aspects pra­tiques sur cer­tains élé­ments fon­da­men­taux et récur­rents du domaine, tels que la rédac­tion des pro­cé­dures, pro­ces­sus, mais éga­le­ment de la docu­men­ta­tion technique.

Mon projet professionnel à l'issu de mon alternance 

L’alternance que j’ai pu réa­li­ser a pro­fon­dé­ment confor­té mon inté­rêt pour le domaine du DM, et m’a confé­ré un inté­rêt par­ti­cu­lier pour l’aspect qualité.

En effet, lors du démar­rage de mon alter­nance, j’étais plus axé sur l’aspect règle­men­taire et je sou­hai­tais donc tra­vailler en tant que Char­gé AR. Cepen­dant, mes mis­sions prin­ci­pales concer­naient majo­ri­tai­re­ment la mise en place d’un SMQ, mis­sions que j’ai appré­cié accom­plir et qui ont gran­de­ment déve­lop­pé mon inté­rêt pour l’aspect qualité.

Ain­si, ayant décou­vert mon inté­rêt pour les deux aspects, je compte axer mes recherches d’emploi sur des postes alliant les deux aspects, et cher­cher des entre­prises auprès des­quelles je pour­rais conti­nuer à tra­vailler sur des mis­sions diver­si­fiées et ain­si par­cou­rir la majo­ri­té des acti­vi­tés d’un Char­gé affaires régle­men­taires et qua­li­té des dis­po­si­tifs médicaux.

Conclusion

Le pas­sage de la classe de risque I à la classe IIa du dis­po­si­tif médi­cal logi­ciel I-GEIA à engen­drer une quan­ti­té impor­tante de démarche à mettre en œuvre pour se confor­mer à la règle­men­ta­tion appli­cable et main­te­nir le mar­quage CE du DM.

Aus­si, à l’issue de mon alter­nance, la mise en place com­plète d’un SMQ au sein de ZOS IS n’a mal­heu­reu­se­ment pas pu être fina­li­sée, cepen­dant de nom­breuses exi­gences ont pu être mise en place et la sen­si­bi­li­sa­tion de l’entreprise à la qua­li­té a pu démarrer.

J’ai éga­le­ment pu tra­vailler en auto­no­mie sur un sujet impor­tant de la norme : la vali­da­tion des appli­ca­tions logi­cielles. J’ai pu res­sor­tir de cette expé­rience de nom­breuses connais­sances qui me ser­vi­ront sans nul doute dans mes futures expé­riences professionnelles.

Aus­si, par la suite, l’entreprise devra conti­nuer à se confor­mer aux exi­gences de la norme ISO 13485 : 2016 et au MDR, pour obte­nir le mar­quage CE (classe IIa).

L’une des phases directes qui pré­cé­de­ra mon départ de l’entreprise sera la mise en appli­ca­tion de la docu­men­ta­tion réa­li­sée et notam­ment des pro­cé­dures. L’entreprise devra éga­le­ment s’assurer d’avoir des preuves docu­men­tées à mon­trer aux éva­lua­teurs (rap­port de revue de direc­tion ect).

Aus­si, l’appel à un consul­tant pour venir en appuie à la mise en confor­mi­té de l’entreprise aux exi­gences qui lui incombe est une oppor­tu­ni­té impor­tante, qui devra per­mette à l’entreprise d’obtenir le mar­quage avant la fin de la période dérogatoire.

Références bibliographiques

[1] C. d’expert Ecomundo, « Dispositifs médicaux : La nouvelle réglementation européenne, applicable en 2021 », Ecomundo.eu, 29 août 2019. https://www.ecomundo.eu/fr/blog/dispositifs-medicaux-reglement-2020 (consulté le 26 juillet 2022).

---

[2] M. Navarro, « Qu’est-ce qu’un système de management de la qualité (SMQ) EN ISO 13485 ? », mauricenavarro, 1 janvier 2022. https://www.mauricenavarro.com/articles/qu-est-ce-qu-un-systeme-de-management-de-la-qualite-smq-en-iso-13485/ (consulté le 26 juillet 2022)

---

[3] M. Navarro, « Glossaire : Définitions de termes techniques en rapport avec la qualité et le génie logiciel pour DM », mauricenavarro. https://www.mauricenavarro.com/ressources/glossaire/ (consulté le 26 juillet 2022).

---

[4] L. Millet, « E-santé : une accélération sans précédent », InstitutMontaigne, 24 septembre 2020. https://www.institutmontaigne.org/blog/e-sante-une-acceleration-sans-precedent (consulté le 26 juillet 2022).

---

[5] L. Meunier, « L’impact de la réglementation concernant les Dispositifs Médicaux sur les différents acteurs de la santé », Synapse-Medicine, 9 décembre 2021. https://synapse-medicine.com/fr/impact-reglementation-dispositifs-medicaux (consulté le 5 août 2022).

---

[6] Snitem, « Logiciel et application en santé : DM ou pas DM ? », calameo, août 2021. https://www.calameo.com/snitem/read/00061054233b7cebc1141 (consulté le 26 juillet 2022)

---

[7] Droit technologie, « Quand le logiciel devient un “dispositif médical” », JurisPharma, 20 novembre 2019. https://www.jurispharma.fr/categories/droit-de-la-sante-23/articles/quand-le-logiciel-devient-un-dispositif-medical-991.htm (consulté le 14 juillet 2022).

---

[8] Elia médical, « Bienvenue chez Elia Médical », Eliamedical-education, 2009. http://www.elia-medical.com/ (consulté le 1 août 2022).

---

[9] Mythologica, « Mythologie grecque : Hygie », Mythologica, 16 novembre 2021. https://mythologica.fr/grec/hygie.htm (consulté le 25 août 2022).

---

[10] F. Barlet, « ZOS Information System : Agence de developpement Informatique sur mesure ». http://www.zos-informationsystem.com/ (consulté le 1 août 2022).

---

[11] Inserm, « Apnée du sommeil : une source de fatigue, mais aussi de maladies cardiovasculaires », Inserm, 1 octobre 2015. https://www.inserm.fr/dossier/apnee-sommeil/ (consulté le 8 août 2022).

---

[12] Centre d’investigation et de recherche sur le sommeil, « L’apnée du sommeil », CHUV.ch, 22 juin 2021. https://www.chuv.ch/fr/sommeil/cirs-home/patients-et-familles/les-troubles-du-sommeil/lapnee-du-sommeil (consulté le 8 août 2022).

---

[13] Data Med Care, « Adel santé : le télésuivi optimisé », adel-santé. https://www.adel-sante.fr/ (consulté le 3 août 2022).

---

[14] Must informatique, « MUST-G5 dans l’assistance respiratoire », Must Informatique. https://www.mustinformatique.com/notre-solution-dans-lassistance-respiratoire/ (consulté le 25 août 2022).

---

[15] ResMed Pty Ltd, « AirView : Logiciel de gestion des données patients », Resmed, août 2020. https://www.resmed.fr/professionnels-de-sante/insuffisance-respiratoire/airview/ (consulté le 8 août 2022).

---

[16] Philips, « DreamStation : Appareils de traitement de l’apnée du sommeil », Philips, décembre 2021. https://www.philips.fr/c-e/hs/apnee-du-sommeil/appareils-apnee-du-sommeil.html (consulté le 8 août 2022).

---

[17] L. Granger, « Concevoir une stratégie : l’analyse SWOT », manager-go.com, 8 juin 2022. https://www.manager-go.com/strategie-entreprise/dossiers-methodes/diagnostic-strategique-swot (consulté le 8 août 2022).

---

[18] Tribune de Genève, « Maladies respiratoires en hausse dans le monde », Tribune de Genève.ch, 17 août 2022. https://www.tdg.ch/maladies-respiratoires-en-hausse-dans-le-monde-486040706927 (consulté le 8 août 2022).

---

[19] « Norme NF EN ISO 13485 - Systèmes de management de la qualité - Exigences à des fins réglementaires », Ed.Afnor, Paris, www.afnor.org, 30 avril 2016. Consulté le : 9 août 2022. [En ligne]. Disponible sur : https://cobaz-afnor-org.ezproxy.utc.fr/notice/norme/nf-en-iso-13485/FA161550?rechercheID=8535472&searchIndex=5&activeTab=all

---

[20] « NF EN ISO 13485/A11 - Dispositifs médicaux - Systèmes de management de la qualité - Exigences à des fins réglementaires », Ed.Afnor, Paris, www.afnor.org, 8 septembre 2021. Consulté le : 22 août 2022. [En ligne]. Disponible sur : https://cobaz-afnor-org.ezproxy.utc.fr/notice/norme/nf-en-iso-13485-a11/FA197434?rechercheID=8752749&searchIndex=7&activeTab=all

---

[21] Adhérent Stratégiqual, « Mise à jour du Système de Management de la Qualité : vous saurez tout le 10 décembre ! », AtlanpoleBiotherapies, 16 novembre 2020. https://www.atlanpolebiotherapies.com/actualites/mise-a-jour-du-systeme-de-management-de-la-qualite-suite-a-lentree-en-vigueur-des-reglements-2017-45-et-2017-746/ (consulté le 26 juillet 2022).

---

[22] C. Lab, « Comprendre la différence entre les processus et les procédures », Optimiso Group, 15 octobre 2020. https://optimiso-group.com/articles/comprendre-enfin-la-difference-entre-processus-et-procedure/ (consulté le 22 août 2022).

---

[23] G. Prome, « Approche par les risques dans l’ISO 13485 », Qualitiso, 23 août 2017. https://www.qualitiso.com/approche-par-les-risques-iso-13485-2016/ (consulté le 18 août 2022).

---

[24] Guillaume Promé, « L’ISO 13485 à l’heure du règlement DM », Qualitiso, 27 novembre 2017. https://www.qualitiso.com/iso-13485-vs-ue-2017-745/ (consulté le 26 juillet 2022).

---

[25] Nouvelle industrie, « ISO 13485 : Système de Management Qualité pour les dispositifs médicaux », Support.nouvelle industrie. https://support.nouvelleindustrie.com/fr/article/iso-13485-syst%C3%A8me-de-management-qualit%C3%A9-pour-les-dispositifs-m%C3%A9dicaux (consulté le 18 août 2022).

---

[26] M. Navarro, « Exigences de la norme EN ISO 13485 », mauricenavarro. https://www.mauricenavarro.com/ressources/exigences-de-la-norme-en-iso-13485/ (consulté le 17 août 2022).

---

[27] Gilbert Farges, « NF EN ISO 13485 : 2016 - Dispositifs médicaux - Systèmes de management de la qualité - Exigences à des fins réglementaires », UTC, 2021.

---

[28] « ISO/TR 80002-2:2017 - Logiciels de dispositifs médicaux - Partie 2 : Validation des logiciels pour les systèmes de qualité des dispositifs médicaux », Ed.Afnor, Paris, www.afnor.org, 1 juin 2017. Consulté le : 22 août 2022. [En ligne]. Disponible sur : https://cobaz-afnor-org.ezproxy.utc.fr/notice/norme/iso-tr-80002-22017/XS130330?rechercheID=8752803&searchIndex=11&activeTab=all

---

[29] Replay webinaire - Fabricants de DM : Réussir sa validation des logiciels du SMQ, (23 juin 2022). Consulté le : 22 août 2022. [En ligne Vidéo]. Disponible sur : https://www.youtube.com/watch?v=NZVPhsMtIso

---

[30] 2017 09 Validation ERP, (5 octobre 2017). Consulté le : 21 août 2022. [En ligne Vidéo]. Disponible sur : https://www.youtube.com/watch?v=5rYCPalhzDA

---

[31] Guillaume Promé, « Validation des logiciels utilisés dans le SMQ », Qualitiso, 14 juin 2018. https://www.qualitiso.com/validation-logiciels-sqm-13485/ (consulté le 27 janvier 2022).

Annexes

Annexe 1 : Extrait du travail réalisé lors de l'étude de la norme ISO 13485v2016

Annexe 2 : Logigramme du processus de validation des applications logicielles