• IDS147 - Mise en place d'un système de management de la qualité selon l'ISO 13485 v2016 : zoom sur la validation des applications logicielles

    Avertissement

    Les projets ou stages publiés auxquels vous accédez sont des rapports d'étudiants et doivent être pris comme tels. Il peuvent donc comporter des imperfections ou des imprécisions que tout lecteur doit admettre et donc supporter. Il ont été réalisés pendant les périodes de formation et constituent avant-tout des travaux de compilation bibliographique, d'initiation et d'analyse sur des thématiques associées aux concepts, méthodes, outils et expériences sur les démarches qualité dans les organisations ou sur les technologies en santé.

    Si, malgré nos précautions, vous avez des raisons de contester ce droit de diffusion libre, merci de nous en faire part (master@utc.fr), nous nous efforcerons d'y apporter une réponse rapide. L'objectif de la présentation des travaux sur le web est de permettre l'accès à l'information et d'augmenter ainsi la qualité des échanges professionnels.

    Nous ne faisons aucun usage commercial des travaux de projet ou de stage publiés, par conséquent les citations des informations et l'emploi des outils mis à disposition sont totalement libres. Dans ce cas, nous vous demandons de respecter les règles d'éthique en citant explicitement et complètement vos sources bibliographiques.

    Bonne lecture...

    Auteure

    Chris­ti­na Roxanne Gbelay

    Contact

    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

    IDS147- Christina_Gbelay - Mémoire
    IDS147- Christina_Gbelay - Mémoire

    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

    searchhomearrow-circle-left