• IDS127 - Nouvelle réglementation Européenne et cartographie des réseaux biomédicaux

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

    Auteurs

    Contacts

    Citation

    A rap­pe­ler pour tout usage : Maria­na Alva­rez, Julien Char­ton, Jor­dy Ramos, Alexan­dra Laurent et Ade­bo­la Fatoke, "Nou­velle régle­men­ta­tion Euro­péenne et car­to­gra­phie des réseaux bio­mé­di­caux", Uni­ver­si­té tech­no­lo­gique de Com­piègne (France), Mas­ter Ingé­nie­rie de la san­té, Mémoire de pro­jet, httpps//travaux.master.utc.fr/, réf n° IDS127, https://doi.org/10.34746/tzhh-8778, jan­vier 2022, url directe : https://travaux.master.utc.fr/formations-master/ingenierie-de-la-sante/ids127

    Résumé

    Le déve­lop­pe­ment infor­ma­tique et tech­no­lo­gique des dis­po­si­tifs médi­caux au sein des éta­blis­se­ments de san­té a contri­bué à l’amélioration des soins. Cepen­dant, l’échange impor­tant de don­nées par les dis­po­si­tifs médi­caux a com­plexi­fié la sécu­ri­té et la sureté des infor­ma­tions com­mu­ni­quées. Pour cette rai­son des régle­men­ta­tions ont vu le jour dans le but de mieux enca­drer ces infor­ma­tions. C'est le cas du nou­veau règle­ment euro­péen 2017/745, qui a élar­git la défi­ni­tion d’un dis­po­si­tif médi­cal et redé­fi­nit les logi­ciels de san­té comme étant des dis­po­si­tifs médi­caux à part entière. Cela induit une sur­veillance et une main­te­nance mais aus­si une ges­tion des risques de ces nou­veaux DM durant tout leur cycle de vie. De plus, la HAS a défi­ni une nou­velle caté­go­rie, les Dis­po­si­tifs Médi­caux Connec­tés (DMC), hié­rar­chi­sés en fonc­tion de leur risque et auto­no­mie vis à vis du patient.
    Ces chan­ge­ments induisent des enjeux tech­niques, éco­no­miques ain­si que la redé­fi­ni­tion des res­pon­sa­bi­li­tés des dif­fé­rents acteurs concer­nés.
    Les éta­blis­se­ments de san­té, comme le centre hos­pi­ta­lier WILLIAM MOREY de Cha­lon sur Saône sont donc impac­tés et se trouvent face à de nou­velles pro­blé­ma­tiques. En effet, le ser­vice bio­mé­di­cal et la DSI devront coopé­rer pour opti­mi­ser le trai­te­ment des patients et gérer au mieux l’utilisation et la sécu­ri­té des DATA à l’hôpital. Une car­to­gra­phie détaillée des DM, DMC, flux de DATA et des acteurs res­pon­sables dans les dif­fé­rents ser­vices devient néces­saire, afin de faci­li­ter la sureté, la dis­po­ni­bi­li­té et l’accès des don­nées aux per­son­nels soi­gnants et amé­lio­rer la qua­li­té de soins du patient.
    Ce Mémoire essaye d’apporter un éclair­cis­se­ment sur la défi­ni­tion d’un DMC et la res­pon­sa­bi­li­té des DATA au sein du bloc opé­ra­toire. En pro­po­sant une orga­ni­sa­tion plus effi­cace entre les ser­vices bio­mé­di­caux et infor­ma­tique à l'avantage du patient. Il a été réa­li­sé en col­la­bo­ra­tion avec le centre hos­pi­ta­lier WILLIAM MOREY de Cha­lon-sur-Saône, grâce aux infor­ma­tions four­nies par le ser­vice bio­mé­di­cal et le ser­vice infor­ma­tique sur le bloc opératoire.

    Abstract

    The tech­no­lo­gi­cal deve­lop­ment of medi­cal devices in hos­pi­tals has contri­bu­ted to the impro­ve­ment of heal­th­care.  Howe­ver, the exchange of data by medi­cal devices has made the secu­ri­ty and pro­tec­tion of com­mu­ni­ca­ted infor­ma­tion more com­plex.  For this rea­son, regu­la­tions have emer­ged to bet­ter manage this information. 

    The new Euro­pean regu­la­tion 2017/745 expan­ded the defi­ni­tion of medi­cal devices and rede­fi­ned heal­th­care soft­ware as medi­cal devices (MD) in its own right. This converts the moni­to­ring and main­te­nance as well as the risk mana­ge­ment of these new MDs throu­ghout their life cycle.  Moreo­ver, the Haute Auto­ri­té de san­té (HAS), or French Natio­nal Autho­ri­ty for Health, has defi­ned a new class of Connec­ted Medi­cal Devices (CMD) hie­rar­chi­zed accor­ding to their risk and auto­no­my with res­pect to the patient.  These changes induce tech­ni­cal and eco­no­mic issues as well as the rede­fi­ni­tion of the res­pon­si­bi­li­ties of the dif­ferent actors concer­ned.  Hos­pi­tals, such as the WILLIAM MOREY hos­pi­tal cen­ter at Cha­lon Sur Saône, are the­re­fore affec­ted and face new pro­blems.  Indeed, the bio­me­di­cal ser­vice and the Infor­ma­tion Tech­no­lo­gy (IT) depart­ment will have to coope­rate to opti­mize the treat­ment of patients and bet­ter manage the use and secu­ri­ty of DATA in the hos­pi­tal. A detai­led map­ping of MDs, DMCs, DATA flows and the res­pon­si­bi­li­ty of the actors in the depart­ments becomes neces­sa­ry, to faci­li­tate the safe­ty, avai­la­bi­li­ty, and access of data to health records and improve the qua­li­ty of patient care. 

    This the­sis attempts to cla­ri­fy the defi­ni­tion of a CMD and the res­pon­si­bi­li­ty of DATA within the ope­ra­ting room, by pro­po­sing a more effi­cient orga­ni­za­tion bet­ween bio­me­di­cal and IT ser­vices to the bene­fit of the patient. This pro­ject has been car­ried out in col­la­bo­ra­tion with the WILLIAM MOREY hos­pi­tal cen­ter in Cha­lon-Sur-saône, where the bio­me­di­cal and IT depart­ment of the ope­ra­ting room pro­vi­ded the infor­ma­tion used.

    Remerciements

    Avant de déve­lop­per ce rap­port, nous tenons à remer­cier toutes les per­sonnes qui ont contri­bué à l’aboutissement de ce projet. 

    Tout d’abord nous remer­çions nos deux sui­veurs UTC, Isa­belle CLAUDE et Jean-Mat­thieu PROT qui sont nos res­pon­sables de filière. Mer­ci pour les conseils appor­tés à chaque jalon ain­si que l’aide don­née lorsque nous en avons eu besoin. Cela nous a per­mis d'être gui­dés tout au long de notre semestre.

    Ensuite nous remer­cions Mr Mazille pour son regard cri­tique, ses conseils et sa dis­po­ni­bi­li­té. Étant ingé­nieur bio­mé­di­cal au centre hos­pi­ta­lier de Cha­lon sur saône, il a pu nous appor­ter les élé­ments concer­nant son expé­rience et nous mettre à dis­po­si­tion et en rela­tion avec les pro­fes­sion­nels qui répon­daient à nos demande pour obte­nir les informations.

    Pour finir, nous remer­cions Mme KONIG Béa­trice pour son regard cri­tique sur notre bibliographique.

    Liste des abréviations

    • AFIB : Asso­cia­tion Fran­çaise des Ingé­nieurs Biomédicaux
    • ANSM : Agence Natio­nale de la Sécu­ri­té du Médi­ca­ments et des Dis­po­si­tifs Médicaux
    • ANSSI : Agence Natio­nale de la Sécu­ri­té des Ser­vices d’Informations
    • CE : Confor­mi­té Européenne
    • CEI : Com­mis­sion Elec­tro­tech­nique Internationale
    • DATA : Terme signi­fiant don­nées Informatique
    • DICOM : Digi­tal Ima­ging and Com­mu­ni­ca­tion in Medicine
    • DM : Dis­po­si­tif Médical
    • DMC : Dis­po­si­tif Médi­cal Connecté
    • DMDIV : Dis­po­si­tif Médi­cal de Diag­nos­tic In Vitro
    • DMIL : Dis­po­si­tif Médi­cal Inté­grant du Logiciel
    • DPI : Dos­sier Patient Informatisé
    • DPO : Délé­gué à la Pro­tec­tion des Données
    • DSI : Direc­tion des Sys­tème Informatique
    • EN : Norme Euro­péenne
    • GE : Géné­ral Électrique
    • GAFA : Géant du Web
    • GAM : Ges­tion Admi­nis­tra­tive du Malade
    • HAD : Hos­pi­ta­li­sa­tion à Domicile
    • HAS : Haute Auto­ri­té de Santé
    • IADE : Infir­mier Anes­thé­siste Diplô­mé d’Etat
    • IBODE : Infir­mier de Bloc Opé­ra­toire Diplô­mé d’Etat
    • ISO : Orga­nisme Inter­na­tio­nal de Normalisation 
    • IUD : Iden­ti­fiant Unique du Dispositif
    • IUP : Iden­ti­fiant Unique du Patient
    • ID : Iden­ti­fiant du Dispositif
    • IP : Iden­ti­fiant de Production
    • NIS : Net­work and Infor­ma­tion Sys­tem Security
    • NF : Norme Fran­çaise
    • UE : Union Euro­péenne
    • ON : Orga­nismes Notifiés
    • OSE : Opé­ra­teurs de Ser­vices Essentiels
    • RGPD : Règle­ment Géné­ral sur la Pro­tec­tion des Données
    • RSSI : Res­pon­sable de la Sécu­ri­té des Sys­tèmes d’Information
    • SIH : Sys­tème d’Information Hospitalier
    • RJ : Regis­te­red Jack ( prise jack en français)
    • HL : Health Level

    Téléchargements

    IDS127-Mémoire
    IDS127-Pos­ter
    IDS127-Outil de cartographie
    IDS127-Mode d'emploi de la cartographie

    Introduction

    Depuis le 26 mai 2021, tous les acteurs et opé­ra­teurs éco­no­miques en lien avec les dis­po­si­tifs médi­caux doivent suivre le nou­veau règle­ment euro­péen 2017/745 [1].

    Ce nou­veau règle­ment élar­git la défi­ni­tion du dis­po­si­tif médi­cal (DM). Le logi­ciel de san­té devient lui aus­si un DM et pos­sède sa clas­si­fi­ca­tion spé­ci­fique. Ce der­nier doit répondre aux exi­gences mises en avant par le règle­ment tout au long de son cycle de vie. En ce qui concerne les dis­po­si­tifs médi­caux connec­tés (DMC), l’HAS a éta­bli une pro­cé­dure de clas­si­fi­ca­tion et per­met d’apporter un cadre réglementaire.

    Plu­sieurs textes tel que le règle­ment 2016/679 (Règle­ment géné­ral de la Pro­tec­tion des Don­nées) [2], la direc­tive 2016/1148 [3], des guides réa­li­sés par l’HAS [4] et l’ANSM [5] ain­si que des publi­ca­tions de l’AFIB [6] per­mettent de défi­nir le logi­ciel de san­té et de sou­li­gner l’importance de la sécu­ri­sa­tion des données.

    Ces Docu­ments impliquent direc­te­ment l'organisation et les res­pon­sa­bi­li­tés des dif­fé­rents acteurs de santé.

    Les éta­blis­se­ments de san­té, comme le centre hos­pi­ta­lier de Cha­lon sur Saône WILLIAM MOREY se retrouvent face à la pro­blé­ma­tique sui­vante : Com­ment appli­quer la nou­velle régle­men­ta­tion aux logi­ciels médi­caux pré­sents au Bloc opératoire.

    L’objectif de ce mémoire est de consi­dé­rer l’impact de ce nou­veau règle­ment, pour per­mettre d’appréhender le déve­lop­pe­ment infor­ma­tique au sein de l’organisation Bio­mé­di­cal. La coor­di­na­tion des ser­vices infor­ma­tiques et bio­mé­di­caux devient un élé­ment essen­tiel pour un fonc­tion­ne­ment effi­cace. Un outil de car­to­gra­phie réper­to­riant les dif­fé­rentes connexions entre équi­pe­ments connec­tés et logi­ciels de san­té entre Bloc opé­ra­toire et les struc­tures infor­ma­tiques, sera pro­po­sé et modi­fiable pour d’autres services.

    I) Contexte

    1. Définition : DM, logiciel de santé, DMC

     

    Afin de com­prendre les dif­fé­rences d’équipements pré­sents au sein du bloc opé­ra­toire il est impor­tant de défi­nir les termes suivants :

    Les Dis­po­si­tifs Médi­caux est tout ins­tru­ment, appa­reil, équi­pe­ment, logi­ciel, implant, réac­tif, matière ou autre article, des­ti­né par le fabri­cant à être uti­li­sé, seul ou en asso­cia­tion, chez l'homme pour l'une ou plu­sieurs des fins médi­cales pré­cises suivantes :

    — diag­nos­tic, pré­ven­tion, contrôle, pré­dic­tion, pro­nos­tic, trai­te­ment ou atté­nua­tion d'une maladie,

    — diag­nos­tic, contrôle, trai­te­ment, atté­nua­tion d'une bles­sure ou d'un han­di­cap ou com­pen­sa­tion de ceux-ci,

    — inves­ti­ga­tion, rem­pla­ce­ment ou modi­fi­ca­tion d'une struc­ture ou fonc­tion ana­to­mique ou d'un pro­ces­sus ou état phy­sio­lo­gique ou pathologique,

    — com­mu­ni­ca­tion d'informations au moyen d'un exa­men in vitro d'échantillons pro­ve­nant du corps humain, y com­pris les dons d'organes, de sang et de tis­sus, et dont l'action prin­ci­pale vou­lue dans ou sur le corps humain n'est pas obte­nue par des moyens phar­ma­co­lo­giques ou immu­no­lo­giques ni par méta­bo­lisme, mais dont la fonc­tion peut être assis­tée par de tels moyens [1].

    Par exemple :  table d’opération, défi­bril­la­teur,  arceau ampli­fi­ca­teur de brillance de bloc opératoire.

    Le logi­ciel de san­té est une solu­tion numé­rique inter­pré­table par un sys­tème infor­ma­tique qui effec­tue une action ou une ana­lyse d’information médi­cale à par­tir de don­nées entrantes per­met­tant de don­ner un résul­tat propre au  béné­fice du patient [4]. (Il peut éga­le­ment être consi­dé­ré comme un DM  selon les cri­tères du règle­ment Euro­péen 2017/745).

    Pour une appli­ca­tion autre que médi­cale, un logi­ciel san­té n’est pas consi­dé­ré comme étant un DM.

    Par exemple : Cpage (ges­tion par­cours patient), logi­ciel de trai­te­ment d’image.

    Un Dis­po­si­tif Médi­cal Connec­té (DMC) est capable, outre sa fonc­tion prin­ci­pale de DM, d’envoyer ou de rece­voir des infor­ma­tions par l’intermédiaire d’un réseau de com­mu­ni­ca­tion inté­gré (Câble, Wifi, Blue­tooth, etc.). D’après l'HAS et la CNEDIMTS, un logi­ciel uti­li­sé à des fins médi­cales ou "par le patient lui-même" et qui dis­pose d’une "fonc­tion de télé­com­mu­ni­ca­tion" est consi­dé­ré comme un DMC [7].  Ces échanges et par­tages de don­nées induisent une opti­mi­sa­tion des soins.

    Est consi­dé­ré comme DMC tout dis­po­si­tif répon­dant à la régle­men­ta­tion euro­péenne 2017/745.

    Par exemple, un logi­ciel de san­té (Sur­gi­me­dia -> super­vi­sion) connec­té à un DM (ampli­fi­ca­tion de brillance) est un DMC puisque celui-ci est des­ti­né à des fins médi­cales et com­porte une fonc­tion de télé­com­mu­ni­ca­tion. Cepen­dant à ce jour, une montre connec­tée n’est pas consi­dé­rée comme DMC mais plu­tôt comme un objet connec­té de san­té car celle-ci intègre un sys­tème de télé­com­mu­ni­ca­tion mais four­nit uni­que­ment des don­nées géné­riques sans fin médicale.

    A contra­rio, le mul­ti­pa­ra­mé­trique est un DM capable d’être relié à d’autres dis­po­si­tifs pour remon­ter des don­nées. Dans ce cas, ils ne sont pas consi­dé­rés comme des DMC.

    Il existe une dif­fé­rence entre un DM, un logi­ciel de san­té et un DMC expli­ci­té dans le tableau (tableau 1) suivant :

    Tableau 1 : Récapitulatif des différences entre dispositif médical, logiciel santé et Dispositif médical connecté (Source : auteur inspiré par le nouveau règlement européen)

    Dans ce contexte, il peut être mis en avant l'arrivée de nou­velles régle­men­ta­tions et des évo­lu­tions régle­men­taires induites par la numé­ri­sa­tion de la san­té. Il est essen­tiel de prendre en compte les risques liés à l’utilisation de ces logi­ciels et DMC (voir cha­pitre des risques). Cela induit la mise en place d’une clas­si­fi­ca­tion de ces dis­po­si­tifs. La clas­si­fi­ca­tion se base sur des cri­tères spé­ci­fiques à chaque type et uti­li­sa­tion médi­cale d'équipement.

    Les cri­tères sont régis par le nou­veau règle­ment, à cela s'ajoutent les recom­man­da­tions de l’HAS [4] et de l’ANSM [5] qui per­met d'établir une éva­lua­tion cli­nique pour que les dis­po­si­tifs puissent obte­nir le mar­quage CE. Cela per­met d’apporter un cadre régle­men­taire au Dis­po­si­tif médi­cal connec­té ain­si qu'au logi­ciel, pour garan­tir une sécu­ri­té et une per­for­mance dans les soins pro­cu­rés aux patients.

    2. Risques liés aux DMC

     

    Le risque est défi­ni comme “Pos­si­bi­li­té, pro­ba­bi­li­té d'un fait, d'un évé­ne­ment consi­dé­ré comme un mal ou un dom­mage” selon Larousse.

    Pour pré­ve­nir et gérer les risques, il faut consi­dé­rer un évé­ne­ment poten­tiel­le­ment dan­ge­reux comme source de risque « que s’il est sus­cep­tible de por­ter atteinte à des enjeux humains, envi­ron­ne­men­taux, éco­no­miques (ou) cultu­rels »[6].

    A ce pro­pos, il existe de nom­breux risques liés au DMC et au DMIL. Les logi­ciels ain­si que les DMC pro­duisent des don­nées qui sont sen­sibles et qui repré­sentent une valeur pour les piratages.(réf AFIB).

    Cela touche le quo­ti­dien des pro­fes­sion­nels et met en dan­ger la prise en charge des patients de dif­fé­rentes façon [8] :

    • Sys­tèmes bio­mé­di­caux paralysés
    • Pla­teaux tech­niques indisponibles
    • Don­nées de pro­gram­ma­tion des soins détruites
    • Sys­tèmes de mes­sa­ge­ries en panne
    • Don­nées de ges­tion et de res­sources humaines perdues
    • Don­nées per­son­nelles de san­té usurpées.

    Pour pré­ve­nir ou limi­ter les risques, les logi­ciels et les DMC doivent répondre aux exi­gences de sûre­té et de per­for­mance. Ce qui per­met d’induire une sécu­ri­sa­tion des don­nées médi­cales du patient pro­duites par un dis­po­si­tif (DATA) et de garan­tir son fonctionnement.

    Répondre aux exi­gences en termes de sécu­ri­té, c’est pro­té­ger l'équipement et toutes les par­ties lui étant atta­chées des menaces exté­rieures qui pour­raient alté­rer son bon fonctionnement.

    Pour appli­quer cela, il faut donc pré­voir les menaces, qui peuvent être :

    Lié aux ser­vices ou à l'établissement ce qui impacte :

    • La san­té des populations
    • Les patients pris en charge dans les établissements
    • Le secret médical
    • La confi­den­tia­li­té des données

    Lié à l’intégrité des équi­pe­ments bio­mé­di­caux comme :

    • La modi­fi­ca­tion des données
    • Les attaques informatiques
    • Des failles structurales.

    Tout cela induit la mise en place et la défi­ni­tion de cri­tères de sécu­ri­té, divi­sés en plu­sieurs par­ties comme l'illustre la figure (figure 1) ins­pi­rée de l'ANSM ci-des­sous [2] :

    Figure 1 : Critères de sécurité (Sources auteurs, inspiré de l'ANSM)

    La confi­den­tia­li­té fait par­tie des élé­ments les plus déli­cats à pro­té­ger, puisqu'elle impacte direc­te­ment la vie pri­vée du patient et doit res­pec­ter le Règle­ment Géné­ral sur la Pro­tec­tion des Don­nées (RGPD, Règle­ment (UE) 2016/679 rela­tif aux don­nées per­son­nelles) [2].

    Il est impor­tant de prendre en compte que plu­sieurs acteurs ont des res­pon­sa­bi­li­tés et des actions à mener contre ces risques. Dans un pre­mier temps, le fabri­cant doit éva­luer son équi­pe­ment et défi­nir sa vul­né­ra­bi­li­té en défi­nis­sant un “niveau accep­table de risques” et en pla­ni­fiant son impact.

    Cou­plé au fabri­cant, dans les éta­blis­se­ments de san­té, le ser­vice Bio­mé­di­cal et l’informatique doivent conjoin­te­ment assu­rer le rôle de pré­ven­tion et de pro­tec­tion basé sur des régle­men­ta­tions et normes.

    Par la mise en place de ces cri­tères de sécu­ri­té, leur éva­lua­tion ain­si que leur sui­vi et la tra­ça­bi­li­té de ceux-ci par les dif­fé­rents acteurs, per­met de mettre en place les exi­gences de sûre­té et d’assurer la pro­tec­tion du patient face aux risques.

    3. La réglementation, les normes et les enjeux

     

    Pour appro­fon­dir le cadre mis en avant dans la pre­mière par­tie, les obli­ga­tions régle­men­taires pré­sentes dans le cycle de vie des logi­ciels ain­si que des dis­po­si­tifs médi­caux (DM), mettent en rela­tion dif­fé­rents règle­ments Euro­péen et normes. À cela s'ajoutent des guides qui per­mettent de faci­li­ter leurs appli­ca­tions. Ain­si, ceci per­met aux acteurs prin­ci­paux de res­pec­ter les exi­gences en vigueur pour les logi­ciels de san­té qui ont pour spé­ci­fi­ci­tés une fina­li­té médi­cale afin d'assurer la sécu­ri­té du patient.

    Dans le contexte de notre pro­jet, le règle­ment UE 2017/745 (C.II/ A. 16.1) qui s’applique aux dis­po­si­tifs médi­caux est la ligne direc­trice de toutes les exi­gences qui doivent être mises en place pour DM, logi­ciel et DMC. La régle­men­ta­tion ou la norme met en avant que les DM doivent être déve­lop­pés et fabri­qués confor­mé­ment à l'état de l'art qui repose sur les prin­cipes du cycle de vie, de ges­tion des risques, ain­si que de la sécu­ri­té de l'information, de la véri­fi­ca­tion et de la vali­da­tion de sa confor­mi­té [1] . Ces cri­tères obli­ga­toires sont éta­blis par le Conseil de l'Union Euro­péenne et par sa Com­mis­sion afin d’obtenir le mar­quage CE. Ce mar­quage auto­rise la libre cir­cu­la­tion des dis­po­si­tifs médi­caux dans l’Union Euro­péen et prouve sa confor­mi­té en termes de sécu­ri­té et de per­for­mance [1].

    D’autres textes doivent être pris en compte tel que le Règle­ment 2016/679 – RGPD qui per­met la ges­tion des risques liés aux logi­ciels. Il per­met d'informer les patients et les pro­fes­sion­nels sur leurs droits concer­nant la ges­tion des don­nées per­son­nelles et garan­tit la confi­den­tia­li­té des don­nées. Pour cela, un Délé­gué à la Pro­tec­tion des Don­nées (DPO) doit être nom­mé par l’établissement. Le DPO a la charge de l'organisation des actions à mener pour éta­blir et mettre en œuvre les lignes direc­trices que per­mettent la mise en place de la RGPD des logi­ciels [2].

    D'ailleurs, la Direc­tive 2016/1148 NIS - Net­work and Infor­ma­tion Sys­tem Secu­ri­ty - (FR arrê­té du 14 sep­tembre 2018). C'est un texte Euro­péen qui struc­ture les orga­nismes per­met­tant de lut­ter contre les cybe­rat­taques et orga­nise la pro­tec­tion des ser­vices essen­tiels des nations de façon homo­gène dans l’ensemble de l’UE. Il per­met la mise en place d’une gou­ver­nance par une stra­té­gie natio­nale mis par l’Agence Natio­nale de la Sécu­ri­té des Sys­tèmes d’Informations (ANSSI). Ce texte ren­force la cyber­sé­cu­ri­té par des Opé­ra­teurs de Ser­vices Essen­tiels (OSE comme les CHU, centre de radio­thé­ra­pie). La mise en place d’un OSE per­met d’établir la sécu­ri­té numé­rique et recueillir les inci­dents par les décla­ra­tions. Cette direc­tive per­met aus­si de ren­for­cer la cyber­sé­cu­ri­té des Fabri­cants de Ser­vice Numé­rique (FSN) [3].

    En plus des règle­ments, des direc­tives, des normes et des guides sont éta­blis par des orga­nismes com­pé­tents comme l’AFNOR, l’HAS, l’ANSM et l’AFIB. Cela per­met d’apporter un aspect opé­ra­tion­nel pour répondre aux exi­gences régle­men­taires que les fabri­cants et les éta­blis­se­ments doivent mettre en place.

    Le tableau(Tableau 2) ci-des­sous met en avant les régle­men­ta­tions obli­ga­toires concer­nant les logi­ciels, les normes qui peuvent leur être appli­quées et les guides qui peuvent ser­vir d’appuis pour les fabri­cants et les éta­blis­se­ments de santé.

    Tableau 2 : Obligations réglementaires et normative dans le cycle de vie des logiciels et DM (source auteur) [1][4], [6], [7], [9][22]
    Obli­ga­toireVolon­taireGuides
    Règle­ment euro­péen 2017/745 rela­tif aux DMNF EN 62304 : Logi­ciels de santé« Guide de qua­li­fi­ca­tion et de clas­si­fi­ca­tion des logi­ciels dans le règle­ment (UE) 2017/745 – MDR et le règle­ment (UE) 2017/746 – IVDR » par la HAS
    Règle­ment 2017/746 rela­tif aux DMDIVNormes ISO/CEI 12207 et ISO/CEI 15288 : Cycle de vie des sys­tèmes et du logicielArt L5311-1-18° du CSP : Les logi­ciels de ges­tion des labo­ra­toires de bio­lo­gie médicale
    Règle­ment (UE) 2016/679 rela­tif aux don­nées personnellesNF EN ISO 13485 : Sys­tème de qua­li­té d’un fabri­cant de DM ou DM DIV« Guide sur les spé­ci­fi­ci­tés d’évaluation cli­nique d’un dis­po­si­tif médi­cal connec­té (DMC) en vue de son accès au rem­bour­se­ment » par la HAS
    Direc­tive (UE) 2016/1148 rela­tif aux cybersécuritéNF EN ISO 14971 : Ges­tion du risque des DM« Cyber­sé­cu­ri­té des dis­po­si­tifs médi­caux inté­grant du logi­ciel au cours de leur cycle de vie » par l’ANSM
     NF EN 62304 : Spé­ci­fi­ci­té de la ges­tion du risque des logi­ciels DM ou DM DIVCer­ti­fi­ca­tion NF - Logi­ciel par l’AFNOR
     NF EN 62366 : Apti­tude à l’utilisation des DM ou DM DIVRecom­man­da­tions pra­tiques « Sécu­ri­té numé­rique des équi­pe­ments bio­mé­di­caux » par l’AFIB
     NF EN 60601-1-4 : Appa­reils élec­tro- médi­caux : sys­tèmes élec­tro-médi­caux programmables 
     NF ISO/ IEC 25051 : 2014 Exi­gences de qua­li­té de logi­ciel et éva­lua­tion par fabricants 

    Tous ces textes per­mettent aux fabri­cants ain­si qu’aux acteurs éco­no­miques et aux éta­blis­se­ments de four­nir les élé­ments per­met­tant de répondre aux exi­gences. Ce cadre régle­men­taire per­met aus­si de mettre en place une ges­tion des risques des don­nées pro­duites par ces équi­pe­ments et de mettre en avant le rôle et les res­pon­sa­bi­li­tés de chaque acteur. Par cela, l'obtention de l’attestation indi­vi­duelle de la cer­ti­fi­ca­tion de confor­mi­té (mar­quage CE) des Dis­po­si­tifs est possible.

    Le patient étant au centre de l’activité, les dis­po­si­tifs sont des outils pour diag­nos­ti­quer, soi­gner, amé­lio­rer, et pré­ve­nir son état de san­té. C’est pour cela qu’une régle­men­ta­tion a été éta­blie, et sa mise en œuvre per­met d’assurer une qua­li­té et une sécu­ri­té des soins durant tout son par­cours de santé.

    En conclu­sion, les exi­gences régle­men­taires per­mettent de four­nir les preuves qui éta­blissent la sécu­ri­té et la per­for­mance des logi­ciels. Les normes per­mettent d’apporter un appui aux dif­fé­rents acteurs pour répondre à celles-ci. En plus de cela l’ANSM, l’HAS et l’AFIB apportent un éclai­rage par la publi­ca­tion de guides, de publi­ca­tions et la mise en place de sui­vi de ges­tion des risques. Toute cette orga­ni­sa­tion, comme le met en avant le sché­ma sui­vant (Figure 2), per­met par son appli­ca­tion de veiller à la per­for­mance dans le but d’assurer la sécu­ri­té auprès du patient.

    Figure 2 : Schéma du cadre réglementaire des dispositifs médicaux aux logiciels de santé (Source auteur inspiré par l'ANSM)

    II) Classification des DM

    1. Classification selon la nouvelle réglementation 2017/745

    La nou­velle régle­men­ta­tion euro­péenne 2017/745, classe les DM selon quatre classes de risque : classe I, classe IIa, classe IIb et classe III. Cette clas­si­fi­ca­tion prend en compte la durée d’utilisation (tem­po­raire, court et long terme), le carac­tère poten­tiel­le­ment inva­sif et le type d’invasivité, la pos­si­bi­li­té ou non de réuti­li­sa­tion, la visée thé­ra­peu­tique ou diag­nos­tique et la par­tie du corps concer­née. Elle inter­vient dans le pro­ces­sus de mar­quage CE pour le fabri­cant et per­met au ser­vice bio­mé­di­cal de déter­mi­ner le niveau de main­te­nance de son dis­po­si­tif médi­cal. La clas­si­fi­ca­tion des DM du bloc opé­ra­toire est illus­trée dans le tableau (Tableau 3) ci-des­sous.

    Tableau 3 : Classe des logiciels selon le règlement 2017/745

    2. Classification selon la HAS

    En plus de la clas­si­fi­ca­tion de la régle­men­ta­tion 2017/745 [1], vu ci-des­sus, la HAS pro­pose une clas­si­fi­ca­tion fonc­tion­nelle basée sur 4 niveaux, allant de A à B, pour allier la san­té et le déve­lop­pe­ment numé­rique [4].

    Le niveau A : Pos­si­bi­li­té de per­son­na­li­sa­tion mais pas d’autonomie

    Ser­vices sup­ports aux patients, aux aidants ou aux pro­fes­sion­nels dans le cadre de soins ou d’optimisation du par­cours de soins ou la ges­tion médico/socio admi­nis­tra­tive sans action directe sur la san­té des patients.

    Le niveau B : Pas de per­son­na­li­sa­tion, ni d’autonomie

    Infor­ma­tion géné­rale de l’utilisateur non per­son­na­li­sée sur les condi­tions de vie, les règles hygié­no- dié­té­tiques, les pathologies/handicaps ou tout état de san­té (au sens large du terme), les par­cours de san­té, de soins ou de vie, etc. Four­nit éga­le­ment des sup­ports ou outils de formation.

    Le niveau C : Per­son­na­li­sa­tion, pas d’autonomie

    Aide à la vie, à la pré­ven­tion, au dépis­tage, au diag­nos­tic, à l’observance, à la sur­veillance ou au trai­te­ment d’une patho­lo­gie, d’un état de san­té ou dans le cadre d’une situa­tion de han­di­cap. Sans auto­no­mie de la solu­tion numé­rique dans la ges­tion de la déci­sion thérapeutique.

    Le niveau D : Per­son­na­li­sa­tion et autonomie

    Ges­tion auto­nome de la déci­sion après ana­lyse des don­nées et diag­nos­tic afin d’ajuster auto­ma­ti­que­ment, le trai­te­ment à admi­nis­trer, sans inter­ven­tion humaine.

    Ain­si, le logi­ciel du bloc opé­ra­toire comme "Cpage'' qui per­met la ges­tion du par­cours médi­cal patient, est clas­sé comme un logi­ciel de niveau A.

    Les logi­ciels du bloc opé­ra­toire de Cha­lon-sur-Saône sont de niveau A. D’autres exemples sont pré­sen­tés et clas­sés sur la pyra­mide (Figure 3) ci-des­sous :

    Figure 3 : Pyramide des logiciels de bloc opératoire selon leur classification (Source auteurs inspiré de l’HAS)

    Pour conclure, l'application des deux clas­si­fi­ca­tions à TELEMIS (logi­ciel de ges­tion de PARCS) montre que le logi­ciel est de classe IIa et de niveau A. Ain­si la clas­si­fi­ca­tion du règle­ment 2017/745 et celle pro­po­sée par l’HAS per­mettent de mettre en avant les exi­gences qui doivent être appli­quées selon le type de logi­ciel uti­li­sé. Ce qui per­met la mise en place d’une clas­si­fi­ca­tion de tous les logi­ciels uti­li­sés à ce jour ain­si que la défi­ni­tion des rôles de chaque acteur. Ceci per­met au patient de béné­fi­cier d’un sys­tème de prise en charge sûr et effi­cace [4].

    3. Res­pon­sa­bi­li­tés et impact des logi­ciels médicaux

     

    Comme vu en amont, les logi­ciels de san­té et les DM connaissent un déve­lop­pe­ment tech­no­lo­gique impor­tant. De plus en plus nom­breux sur le mar­ché et les pla­teaux tech­niques dans les filières de soins, ils dépendent d’une grande inno­va­tion tech­no­lo­gique et digi­tale qu’il faut aujourd’hui contrô­ler pour maî­tri­ser leur impact. Pour cela, il est impor­tant de défi­nir les res­pon­sa­bi­li­tés des dif­fé­rents acteurs liées à ces DMC.

    L’entrée en vigueur du règle­ment euro­péen 2017/745 [1] a redé­fi­nit la clas­si­fi­ca­tion de ces logi­ciels de san­té en DM ou DMC. Cette nou­velle régle­men­ta­tion ren­force les exi­gences CE, ce qui induit un contrôle des nou­veaux cer­ti­fi­cats mais éga­le­ment une véri­fi­ca­tion de l’usage cli­nique asso­cié à ces certificats.

    L'ANSM [5] et l’HAS [4] ont appor­té un éclai­rage sur cette régle­men­ta­tion, comme vu pré­cé­dem­ment, de manière à défi­nir, pour les dif­fé­rents opé­ra­teurs, la qua­li­fi­ca­tion de ces pro­duits comme DM et leur clas­si­fi­ca­tion. Cette nou­velle régle­men­ta­tion s’applique sur l’ensemble du cycle de vie de ces logi­ciels de san­té DM et DMC [17].

    En ce qui concerne les exi­gences appli­quées aux fabri­cants, il devra éva­luer pour chaque solu­tion numé­rique la fonc­tion de la des­ti­na­tion et les spé­ci­fi­ci­tés carac­té­ri­sant la fina­li­té médi­cale de son pro­duit. Ain­si, si son logi­ciel dis­pose du sta­tut de DM ou DM DIV, il devra défi­nir sa clas­si­fi­ca­tion selon les annexes VIII des règle­ments DM 2017/745 [1] et DMDIV 2017/746 [22]. Cela amè­ne­ra à la reclas­si­fi­ca­tion de cer­tains de ces logi­ciels, jusqu’à pré­sent en classe I, vers une classe IIa, IIb voir III. Ils devront donc démon­trer la confor­mi­té aux exi­gences essen­tielles appli­cables pour les DM ou DM DIV de cette classe. L'intervention d’ON sera ain­si néces­saire dans cer­tains cas pour l'obtention du mar­quage CE [23]. Les inci­dents pos­sibles seront éga­le­ment à prendre en compte par le fabri­cant (rap­pel, dif­fu­sion de nou­velles ver­sions logi­ciels cor­rec­tives). Cela passe par la mise en place d’une maté­rio­vi­gi­lance et d’un sui­vi post-commercial.

    Le fabri­cant devra mettre en place une sur­veillance des pro­duits après leur mise sur le mar­ché et ce tout au long de leur cycle de vie. D'ailleurs, en fonc­tion de l'intérêt cli­nique du DMC, le prix de rem­bour­se­ment voire le prix limite de vente de ces logi­ciels sera impac­té [24]. Les DMC intègrent  aus­si une fonc­tion de trai­te­ment des don­nées per­son­nelles. Le fabri­cant ou le dis­tri­bu­teur devra donc joindre un dos­sier de décla­ra­tion indi­quant que son pro­duit suit la légis­la­tion RGPD [2] pour pou­voir être remboursé.

    Outre les fabri­cants, les éta­blis­se­ments de san­té vont éga­le­ment être impac­tés [25]. Une col­la­bo­ra­tion entre le ser­vice bio­mé­di­cal et le ser­vice infor­ma­tique sera néces­saire pour veiller au bon fonc­tion­ne­ment des logi­ciels de san­té DM et DMC. Le ser­vice bio­mé­di­cal devra donc défi­nir à par­tir des docu­men­ta­tions fabri­cant l’utilisation des logi­ciels de san­té DM et des DMC mais éga­le­ment les per­sonnes aptes à les uti­li­ser (méde­cin, IBODE, tech­ni­cien, phar­ma­cien…). Du fait du pas­sage de logi­ciels de san­té à celui de DM ou DMC les main­te­nances et l’entretien de ses pro­duits se feront en col­la­bo­ra­tion avec la DSI. Le ser­vice bio­mé­di­cal devra s’occuper de la par­tie maté­rielle alors que la DSI s’occupera des cybe­rat­taques, des mises à jour ou encore des com­po­sants infor­ma­tiques inté­grant les logi­ciels de san­té DM et DMC. Cette main­te­nance en par­te­na­riat per­met­tra de pré­ve­nir les inci­dents de maté­rio­vi­gi­lance liés à l’utilisation de DMC.  La figure sui­vante (Figure 4) montre cette coopé­ra­tion à mettre en place entre le ser­vice bio­mé­di­cal et la DSI pour gérer au mieux les DMC, dans le but de rendre le trai­te­ment du patient optimal.

    Figure 4 : Coopération des acteurs pour les logiciels de santé DM et DMC (source auteur)

    Il sera néces­saire d’avoir un sui­vi de l’ensemble des DMC de l’infrastructure pour pré­ve­nir les dif­fé­rents risques. Pour cela une docu­men­ta­tion de l’infrastructure, des péri­phé­riques et outils connec­tés devra être faite dans le but d’avoir une sur­veillance de ces appa­reils dans l’établissement. Cette iden­ti­fi­ca­tion du maté­riel per­met­tra au ser­vice bio­mé­di­cal, de gérer plus faci­le­ment les main­te­nances ain­si que les habi­li­ta­tions des inter­ve­nants et utilisateurs.

    Le ser­vice bio­mé­di­cal, en par­te­na­riat avec la DSI, devra gérer les don­nées des logi­ciels de san­té DM et DMC de leur mise en ser­vice jusqu’à leur mise hors ten­sion. Effec­ti­ve­ment, à la dif­fé­rence d’un DM, un logi­ciel de san­té DM et DMC stock et traite les don­nées per­son­nelles du patient qui devront être enre­gis­trées et sécu­ri­sées avant son recyclage.

    Le der­nier chaî­non de ce cycle impac­té par la nou­velle régle­men­ta­tion est le patient. Assu­ré­ment, le patient devien­dra davan­tage acteur de son trai­te­ment en ayant accès à toutes les don­nées de son dos­sier. Il devra alors bien com­prendre les risques liés à ce type de pro­duit et toute la légis­la­tion qui lui per­met d’être pro­té­gé en cas de défaillance du maté­riel ou d’une attaque de don­nées. Mais pour cela il sera néces­saire que tous les opé­ra­teurs cités pré­cé­dem­ment prennent à cœur leur rôle pour per­mettre au patient d’avoir une qua­li­té de soin optimale.

    Cette nou­velle régle­men­ta­tion per­met ain­si d’attribuer les res­pon­sa­bi­li­tés néces­saires pour le bon fonc­tion­ne­ment et la sécu­ri­té d’utilisation des DM et DMC. 

    D’autres opé­ra­teurs des ser­vices des éta­blis­se­ments de san­té, tel que dans le bloc opé­ra­toire, vont voir leurs acti­vi­tés impac­tées. Au bloc opé­ra­toire le ser­vice bio­mé­di­cal est en contact étroit avec dif­fé­rents corps de métier pour veiller au bon fonc­tion­ne­ment des DMC et de leur uti­li­sa­tion lors des opé­ra­tions. Le ser­vice bio­mé­di­cal doit donc prendre en compte les demandes et avis de cha­cun de ses acteurs (méde­cin, IBODE, cadre de san­té, phar­ma­cien…) [26].

    III) Rôles et responsabilités

    1. Processus général

     

    La fron­tière entre l'ingénierie Bio­mé­di­cale et l’Informatique devient plus mince au fil du temps. La ges­tion et la maî­trise des don­nées patients est un domaine essen­tiel reliant ces ser­vices. Il est donc impor­tant de défi­nir le péri­mètre d’action de cha­cun, pour qu’ils puissent tra­vailler ensemble.

    Les “res­pon­sa­bi­li­tés” étant tou­jours un sujet déli­cat au sein des éta­blis­se­ments de san­té, elles se sont accrues avec le déve­lop­pe­ment rapide des Dis­po­si­tifs Médi­caux Connec­tés et des logi­ciels dans les ser­vices de soins.

    Pour sécu­ri­ser les Don­nées de san­té, il faut une bonne coor­di­na­tion des ser­vices infor­ma­tiques et bio­mé­di­caux. Per­met­tant une effi­ca­ci­té lors des pannes et une amé­lio­ra­tion du ser­vice vis à vis du patient.

    Cepen­dant les deux ser­vices n’ont pas tout à fait les mêmes objec­tifs, le bio­mé­di­cal ayant plus un but de fonc­tion­ne­ment et de moyen alors que l’informatique, la sécurité.

    D’ou l’importance de mutua­li­sa­tion et coor­di­na­tion des services.

    La car­to­gra­phie des pro­ces­sus (Figure 5) de res­pon­sa­bi­li­té, ci-des­sous, per­met d’avoir une vue d’ensemble de l'amélioration pos­sible dans ce domaine.

    Ils sont défi­nis en 3 Pro­ces­sus : Mana­ge­ment, Opé­ra­tion­nel et Sup­port. Cha­cun de ces pro­ces­sus sera détaillé par la suite.

     
    Figure 5 : Cartographie des Processus de responsabilité des données patient

    a.      Processus : Management

    Le but de ce pro­ces­sus est de gérer et mutua­li­ser les res­sources. Dans un pre­mier temps, l’enjeu sera de défi­nir les objec­tifs et actions à mener pour per­mettre une bonne com­mu­ni­ca­tion entre les dif­fé­rents acteurs (Ingé­nieur bio­mé­di­cal, Ser­vice Infor­ma­tique, Uti­li­sa­teurs, Fabricants).

    Un res­pon­sable de chaque sec­teur peut être dési­gné pour per­mettre un sui­vi rapide du pro­jet, ou d’un sys­tème exis­tant. De plus, la com­mu­ni­ca­tion est un élé­ment cen­tral. Défi­nir un inter­lo­cu­teur res­pon­sable pour chaque sec­teur per­met­tra de réduire les acteurs et de gagner en efficacité.

    b.      Processus : Opérationnel

    Le but de ce pro­ces­sus concerne la maî­trise, la sécu­ri­sa­tion et la flui­di­té des données.

    Pour bien défi­nir un risque, il faut connaître le fonc­tion­ne­ment de son équi­pe­ment. Le ser­vice bio­mé­di­cal conjoin­te­ment au fabri­cant peuvent pro­po­ser, si besoin, des ses­sions de for­ma­tions aux équipes du bloc opé­ra­toire, telles que les infir­mières, les IBODE, les IADE, les chirurgiens…

    Il est ques­tion ici du maté­riel com­mun au ser­vice de soins comme les res­pi­ra­teurs, pousse-seringues, équi­pe­ment de moni­to­rage connec­tés et bien d’autres. Cepen­dant, le cœur du pro­ces­sus est la pro­tec­tion des DATA.

    Pour cela il est impor­tant d’éviter des pro­blèmes de failles de réseau, dû à des sys­tèmes d’exploitation trop anciens, un manque de mises à jour ou des logi­ciels mal­ware et ran­som­ware. Ain­si que les faille d’ordre “humaines” (mail conte­nant un virus, disque dur externe vérolé)

    La dif­fi­cul­té prin­ci­pale ici, est la pro­tec­tion de ces équi­pe­ments et du réseau infor­ma­tique de l’infrastructure, sans entra­ver la flui­di­té des DATA qui peuvent deve­nir des infor­ma­tions vitales. La Direc­tion des ser­vices infor­ma­tique a sou­vent une démarche de pro­tec­tion en ver­rouillant le réseau, au contraire de l'ingénierie bio­mé­di­cale qui pré­fère la cir­cu­la­tion des données.

    La figure sui­vante (Figure 6) met en avant la rela­tion entre la cir­cu­la­tion des don­nées sou­hai­té par l'ingénierie bio­mé­di­cale et sa sécu­ri­sa­tion deman­dé par l’informatique :

     
    Figure 6 : Balance entre la sécurité des données et sa circulation. (Source : auteurs inspirés du document AFIB “Groupe de travail AFIB 2019–2020 : sécurité numérique des équipements biomédicaux”[6])

    Il y a donc un com­pro­mis à effec­tuer entre sécu­ri­té et cir­cu­la­tion des don­nées, et en cas de dys­fonc­tion­ne­ment, l’intervention doit être rapide et faite à la per­sonne adéquate.

    c.       Processus : Support

    Le but de ce pro­ces­sus est le sup­port qui peut être appor­té à ces objec­tifs. Le thème du bud­get devra être abor­dé. Un cas clas­sique dans les ins­ti­tu­tions hos­pi­ta­lières est “d’acheter” en fonc­tion des bud­gets attri­bués ou du bud­get res­tant. Par exemple, un équi­pe­ment infor­ma­tique peut être ache­té par le ser­vice bio­mé­di­cal et vice ver­sa en fonc­tion des bud­gets res­tants, cela impacte direc­te­ment la res­pon­sa­bi­li­té des acteurs.

    La pro­po­si­tion de mutua­li­sa­tion de cer­tains finan­ce­ments pour­rait être une alter­na­tive avan­ta­geuse. Paral­lè­le­ment au finan­ce­ment, les équipes peuvent se mutua­li­ser et les acteurs comme le fabri­cant sont impli­qués comme sup­port à cela. Il s’agit éga­le­ment ici de gérer le cycle de vie des dis­po­si­tifs de san­té, par le trans­fert ou l’effacement des don­nées patient vers un équi­pe­ment plus récent, si ce der­nier est des­ti­né au rebut.

    Cette car­to­gra­phie (figure 5) s’appuie sur des pro­po­si­tions faites dans le docu­ment “Groupe de tra­vail AFIB 2019–2020 : sécu­ri­té numé­rique des équi­pe­ments bio­mé­di­caux “ [6]

    Beau­coup des élé­ments abor­dés sont déjà mis en place dans les éta­blis­se­ments de soins. Cet outil a pour but d’avoir une vue d’ensemble, pour pro­po­ser un outil concret comme une car­to­gra­phie du réseau. Cepen­dant il sera dif­fi­cile de déli­mi­ter le péri­mètre d'intervention de chaque acteur, mais il sera pos­sible d’apporter un éclair­cis­se­ment sur le rôle du ser­vice bio­mé­di­cal de Cha­lon-sur-Saône, grâce aux connais­sances que nous a appor­tées le tech­ni­cien sur le dit service.

    2. Analyses du parcours de la DATA présente dans le parcours de soins.

    L’évolution de la tech­no­lo­gie médi­cale a consi­dé­ra­ble­ment aug­men­té la quan­ti­té d’informations du sys­tème sani­taire. Il est néces­saire de connaître la pro­ve­nance et la des­ti­na­tion de ces données.

    La connais­sance du par­cours des don­nées au sein de l’hôpital per­met d’identifier le per­son­nel com­pé­tent pour la réso­lu­tion des pro­blèmes et de sécu­ri­ser les don­nées en blo­quant tout échange au bon moment. Pour suivre cette DATA, il est indis­pen­sable d’avoir une car­to­gra­phie du réseau dans l’infrastructure concer­née. Ain­si, il est pri­mor­dial d’identifier les DMC qui com­mu­niquent entre eux ou avec des logi­ciels à l’intérieur et à l’extérieur de la salle ain­si que les serveurs.

    Des infor­ma­tions tran­sitent de la pré­ad­mis­sion jusqu’à la salle de réveil. Il faut défi­nir com­ment celles-ci naviguent entre les dif­fé­rents ser­vices de l'établissement pour en assu­rer une sécu­ri­té et une sûreté.

    La figure sui­vante (Figure 7) pré­sente les dif­fé­rentes étapes du par­cours de soin du patient :

    Figure 7 : Schéma illustratif du parcours de soin du patient (Source : auteur)

    Pour com­men­cer le patient est accueilli, son dos­sier admi­nis­tra­tif est créé et tra­cé par une secré­taire d'accueil dans un logi­ciel per­met­tant de mettre en place la Ges­tion Admi­nis­tra­tive du Malade (GAM) comme Cpage [27]. Ce logi­ciel ali­mente le sys­tème d’information de l’établissement (SIH), il per­met de créer un dos­sier numé­rique qui a pour objec­tif de garan­tir une conti­nui­té de la ges­tion admi­nis­tra­tive (IUP, iden­ti­té, fac­tu­ra­tion…) au patient.

    A la suite de son accueil, le patient va rejoindre un ser­vice d'hospitalisation (ambu­la­toire ou spé­ci­fique). A cette étape un dos­sier de soin va être créé et ins­ti­tué dans le SIH [28] par un logi­ciel métier comme Cris­tal [29] ou Easi­ly qui per­met­tra de par­ta­ger entre les dif­fé­rents acteurs de soins (aides-soi­gnantes, infir­mières, méde­cins, chi­rur­gien, tech­ni­ciens para­mé­di­cales…) d'accéder au Dos­sier Patient Infor­ma­ti­sé. Ce dos­sier conserve et sécu­rise les infor­ma­tions de san­té concer­nant le sui­vi, les trai­te­ments, les résul­tats d’examens, les aller­gies… et per­met un échange entre les dif­fé­rents pro­fes­sion­nels. Ceci per­met une coor­di­na­tion et une conti­nui­té des soins pro­po­sés au patient. La mise en place d’un DPI lui per­met aus­si d’avoir toutes les infor­ma­tions concer­nant son hos­pi­ta­li­sa­tion (trans­pa­rence des soins).

    Ensuite le patient va être pris en charge pour aller au bloc opé­ra­toire. Le DPI sera com­plé­té par les acteurs de soins puis il sera ajou­té le dos­sier d'anesthésie. Le dos­sier d’anesthésie est ali­men­té par le logi­ciel métier des anes­thé­sies comme cli­ni­soft CCA. Le DPI est ali­men­té par les DATA venant des DM, logi­ciels et des DMC uti­li­sés au bloc opé­ra­toire pour réa­li­ser l’acte comme TELEMIS, DOSEWATCH, et Sur­gi­me­dia. Cela entraîne un flux impor­tant de don­nées, ce qui induit la mise en place d’une orga­ni­sa­tion, une sécu­ri­sa­tion ain­si que d’une répar­ti­tion des rôles et des res­pon­sa­bi­li­tés. La par­tie sui­vante pré­sen­te­ra une car­to­gra­phie met­tant en avant cette organisation.

    Après le bloc opé­ra­toire, le patient va pas­ser en salle de réveil, à cette étape le DPI est com­plé­té par les don­nées de réani­ma­tions, de trai­te­ments post opératoire…

    Pour finir le patient retourne à domi­cile, son GAM va être clô­tu­ré par la fac­tu­ra­tion et son DPI va être trans­mis à son méde­cin trai­tant. Cela per­met­tra de pour­suivre les soins même hors de l’établissement, comme l'Hospitalisation à Domi­cile (HAD) qui du coup induit un échange de DATA entre le patient et le méde­cin par des DMC. Toutes ces don­nées seront conser­vées dans le SIH de l’établissement. Cela per­met de pour­suivre les soins mais aus­si de mettre en place une sécu­ri­té et une trans­pa­rence sur les actes médi­caux réa­li­sés ain­si que les don­nées per­son­nelles de moni­to­rage et de trai­te­ment du patient.

    Nous consta­tons que la sécu­ri­té des DATA est pri­mor­diale à chaque étape de la prise en charge du patient qui entre pour un acte chi­rur­gi­cal. L'organisation du flux de don­nées vers le SIH est pri­mor­diale car ceci per­met­tra de défi­nir les acteurs ain­si que les rôles et res­pon­sa­bi­li­tés qui leur sont liés. Grâce à ces infor­ma­tions, le main­tien des per­for­mances et de la sécu­ri­té de ces équi­pe­ments sera pos­sible (soi­gnants, para­mé­di­caux, ser­vice infor­ma­tique, ser­vice bio­mé­di­cale...), leurs rôles ain­si que leur res­pon­sa­bi­li­té pour per­mettre le main­tien de la per­for­mance de ces équi­pe­ments infor­ma­tiques. Mais aus­si garan­tir une conti­nui­té, une trans­pa­rence et une sécu­ri­té des soins au patient. Pour cela la légis­la­tion impose un cadre et des orga­nismes comme l’ANSM, l’HAS et l’AFIB apporte des guides, des publi­ca­tions pour aider l'établissement à mettre en place cette orga­ni­sa­tion et déter­mi­ner le rôle de cha­cun [4][6].

    IV) Cartographie

    Pour suivre et sécu­ri­ser les infor­ma­tions utiles au bloc opé­ra­toire, les tech­ni­ciens et ingé­nieurs bio­mé­di­caux ont une image men­tale du réseau du bloc opé­ra­toire. Chaque car­to­gra­phie men­tale peut être légè­re­ment dif­fé­rente entre les acteurs du fait de la plu­ri­dis­ci­pli­na­ri­té d’un tel ser­vice. Pour pal­lier ce pro­blème qui peut entraî­ner des risques majeurs du fait ne pas avoir d’outils adap­tés, mais aus­si pour aider à la com­pré­hen­sion et défi­nir les res­pon­sa­bi­li­tés des acteurs, il est essen­tiel de faire une car­to­gra­phie phy­sique du réseau tenu à jour à chaque implé­men­ta­tion de nou­veaux appa­reils ou de nou­velles connexions.

    Cette car­to­gra­phie aura pour objec­tif de défi­nir la res­pon­sa­bi­li­té des uti­li­sa­teurs des DMC et logi­ciels connec­tés. En effet, les uti­li­sa­teurs de tels dis­po­si­tifs doivent être conscients des risques qui y sont asso­ciés mais aus­si savoir la res­pon­sa­bi­li­té qui leur incombe dans l’utilisation des don­nées four­nies. Avec cette car­to­gra­phie, ils pour­ront plus faci­le­ment suivre le par­cours des don­nées et contac­ter la per­sonne adé­quate en cas de dysfonctionnement.

    Ain­si, les uti­li­sa­teurs feront appel à la per­sonne com­pé­tente pour résoudre le pro­blème ren­con­tré. Par exemple, si le même pro­blème se pré­sente dans 2 salles de bloc opé­ra­toire avec un réseau iden­tique, il sera plus facile de diag­nos­ti­quer le pro­blème. Dans un tel cas, il pour­rait s’agir d’un pro­blème de trans­fert de don­nées vers le ser­veur, il fau­dra alors contac­ter la DSI. Si le pro­blème a lieu uni­que­ment dans une salle, alors l’utilisateur du DMC appel­le­ra le ser­vice bio­mé­di­cal pour consta­ter si le pro­blème vient du DM, du logi­ciel de san­té ou d’un pro­blème de réseau. Ain­si le ser­vice bio­mé­di­cal pour­ra aisé­ment défi­nir d’où vient le dys­fonc­tion­ne­ment et inter­ve­nir rapi­de­ment. En effet, la loca­li­sa­tion du pro­blème est alors plus aisée pour le ser­vice bio­mé­di­cal et peut ain­si inter­ve­nir plus rapi­de­ment pour évi­ter de ralen­tir la prise en charge du patient au bloc opératoire.

    Le der­nier inté­rêt, et non des moindres, d’une car­to­gra­phie détaillée d’un ser­vice de bloc opé­ra­toire est l’intégration du type de DATA créé et trans­mis. Le for­mat de l’information per­met de rele­ver sa cri­ti­ci­té [6] et ain­si pré­voir une ges­tion de risque effi­cace en cas de dys­fonc­tion­ne­ment ou de cyber­cri­mi­na­li­té. Le codage de la DATA est impor­tant car il va per­mettre de sto­cker des infor­ma­tions du patient et du trai­te­ment néces­saire au bon dérou­le­ment de la prise en charge du patient tout en garan­tis­sant une pro­tec­tion de ces don­nées [2].

    La car­to­gra­phie sui­vante (Figure 8) est propre au bloc opé­ra­toire de Cha­lon-Sur-Saône, les flux de DATA entre chaque sys­tème y sont repré­sen­tés [2], [6].

     
    Figure 8 : cartographie du bloc opératoire de Chalon-Sur-Saône WILLIAM MOREY

    a. Interaction DM-patient

    Au bloc opé­ra­toire les dis­po­si­tifs médi­caux connec­tés au patient col­lectent les infor­ma­tions sur les para­mètres phy­sio­lo­giques qui per­mettent une ana­lyse et adap­ta­tion par le per­son­nel médi­cal. C’est le cas du ven­ti­la­teur et de la cœlio­sco­pie sur le sché­ma ci-des­sus (cadre orange).

    Le ven­ti­la­teur récu­père les infor­ma­tions sur le volume cou­rant, volume minute, la pres­sion expi­ra­toire posi­tive (PEP) et le débit d’insufflation. Le cli­ni­cien inter­vien­dra sur ces para­mètres en fonc­tion des besoins du patient. La coe­lio­sco­pie per­met d’enregistrer les images et/ou vidéo pour un diag­nos­tic ou un trai­te­ment ulté­rieur. Ces infor­ma­tions récu­pé­rées par les DM sont gérées par le ser­vice bio­mé­di­cal, garant des dis­po­si­tifs médi­caux dans l’hôpital.

    b. Echange de données entre DMC et serveurs

    Les infor­ma­tions vitales recueillies par les DM sont envoyées par câbles RJ45 à tra­vers les prises sur les ser­veurs ou par rela­tion de DICOMISATION (Dose­watch). Par exemple, le ven­ti­la­teur sur le sché­ma ci-des­sus est relié au boî­tier ebox par câble série  pour les échanges de don­nées vitales. Quant à la cœlio­sco­pie, elle trans­fère les images et/ou vidéo par câble vidéo (HDMI/S­DI/s-Vidéo) avec le DMC SURGIMEDIA, qui per­met la Dico­mi­sa­tion des don­nées. Ces infor­ma­tions étant en pro­ve­nance des DM entrent donc dans le champ de com­pé­tences du ser­vice bio­mé­di­cal, en revanche les logi­ciels aux­quels ils sont connec­tés sont du res­sort de la DSI (Ser­veurs (PACS, DPI…). A ce niveau un par­te­na­riat entre ser­vice bio­mé­di­cal et DSI est for­te­ment recom­man­dé pour faci­li­ter la dis­po­ni­bi­li­té et l’accès des don­nées aux per­son­nels soignants.

    c. Transmission des données du serveur sur le réseau

    Les ser­veurs conver­tissent dans leur ensemble les don­nées issues des DMC en for­mat HL7. Le for­mat HL7 est une norme inter­na­tio­nale qui per­met les échanges infor­ma­ti­sés de don­nées cli­niques, finan­cières et admi­nis­tra­tives entre sys­tèmes d'information hos­pi­ta­liers. Grâce à cette opé­ra­tion, les don­nées sont envoyées sur le réseau prin­ci­pal de l’établissement (Figure 9). Ce qui per­met au per­son­nel soi­gnant de consul­ter le dos­sier patient dans n’importe quel ser­vice. Ain­si par l’intermédiaire du sous répar­ti­teur, le boî­tier Ebox envoie les don­nées vitales en for­mat HL7 sur le réseau DPI par fibre. Le réseau DPI, ser­veur TELEMIS et SURGIMEDIA sont reliés à leur tour par fibre au bureau vir­tuel qui n’est rien d’autre qu’un ordi­na­teur per­met­tant l’accès sur toutes les autres inter­faces tel que le SURGIMEDIA, le ser­veur TELEMIS et DOSEWATCH. Ces infor­ma­tions sont gérées par le ser­vice infor­ma­tique, qui garan­tit la sûre­té des don­nées et le fonc­tion­ne­ment des dif­fé­rents ser­vices à l’aide d’un ser­veur Back-up, per­met­tant de pré­ve­nir un pro­blème lié au réseau via une dupli­ca­tion des don­nées. Ces infor­ma­tions envoyées sur le réseau sont gérées par le ser­vice informatique.

    Figure 9 : Transmission des données (Source Auteurs)

     

    Conclusion

    Par l'application de la nou­velle régle­men­ta­tion Euro­péenne 2017/745 et 2017/746, les dis­po­si­tifs médi­caux font face à de nou­velles exi­gences. Cela concerne notam­ment les logi­ciels de san­té. Tout cela, impact l’implantation, l’utilisation, l’organisation et la redé­fi­ni­tion des res­pon­sa­bi­li­tés au sein des éta­blis­se­ments de santé.

    Dans ce mémoire, Il a pu être éta­bli les élé­ments qui posent le contexte avec la défi­ni­tion des dis­po­si­tifs médi­caux et des logi­ciels de san­té. Ain­si que l’impact des logi­ciels et des DMC au sein du sys­tème de san­té et de la prise en charge du patient.

    A la suite il a été mis en avant la vision régle­men­taire et nor­ma­tive qui a per­mis de mettre en évi­dence des exi­gences et une ges­tion des risques pour appor­ter de la sécu­ri­té, une per­for­mance des logi­ciels et des flux de DATA pour garan­tir au patient des soins de qua­li­té et un par­cours adap­té à son besoin.

    Une mise en rela­tion entre contexte régle­men­taire et le bloc opé­ra­toire a pu être éta­blie. Cela a per­mis de réa­li­ser une car­to­gra­phie des logi­ciels et des flux de DATA pré­sents au sein du bloc opé­ra­toire qui per­met­tra de défi­nir le rôle, les acteurs et leurs res­pon­sables. Il est dif­fi­cile de répar­tir des rôles dis­tincts entre le ser­vice infor­ma­tique et le ser­vice biomédical.

    A la suite d’entretien avec les dif­fé­rents acteurs de Cha­lon-sur-Saône WILLIAM MOREY et selon la poli­tique de l’établissement et son orga­ni­sa­tion his­to­rique, la mutua­li­sa­tion des deux ser­vices ou la mise en place d’une orga­ni­sa­tion per­met­tant de les mettre en lien n’est pas la solu­tion la plus opti­male pour répondre aux exi­gences garan­tis­sant une sécu­ri­té et une per­for­mance aux patients.

    Dans ce cas, il peut être envi­sa­ger les solu­tions suivantes :

    • Créer une divi­sion infor­ma­tique bio­mé­di­cale au sein du ser­vice biomédical.
    • Déve­lop­per les com­pé­tences des techniciens.
    • Créer un groupe de tra­vail DSI/Biomédical où mutua­li­ser les deux ser­vices mais sous cer­taines condi­tions (accord et volon­té de la direc­tion, des ser­vices et d’un gain de productivité).

    Références bibliographiques

    [1]           « Règlement (UE) 2017/745 du Parlement européen et du Conseil du 5 avril 2017 relatif aux dispositifs médicaux, modifiant la directive 2001/83/CE, le règlement (CE) n° 178/2002 et le règlement (CE) n° 1223/2009 et abrogeant les directives du Conseil 90/385/CEE et 93/42/CEE (Texte présentant de l’intérêt pour l’EEE. ) », Journal officiel de l’Union européenne, https://eur-lex.europa.eu, mai 2017.
     
    [2]           Commission Européenne, « Règlement (UE) 2016/679 », ed. ec, www.ec.europa.eu, Règlement, mai 2016. [En ligne]. Disponible sur : https://cobaz-afnor-org.ezproxy.utc.fr/notice/reglementation/rg-679-2016/FR154349?rechercheID=3309049&searchIndex=4&activeTab=reglementations
     
    [3]           « Directive 2016/1148/CE mesures destinées à assurer un niveau élevé commun de sécurité des réseaux et des systèmes d’information. », ed. ec, www.ec.europa.eu, juill. 2016.
     
    [4]           HAS, « Guide - Classification fonctionnelle,  selon leur finalité d’usage, des  solutions numériques utilisées  dans le cadre de soins  médicaux ou paramédicaux », HAS - Haute autorité de santé, févr. 17, 2021. https://www.has-sante.fr/jcms/p_3238360/fr/classification-fonctionnelle-selon-leur-finalite-d-usage-des-solutions-numeriques-utilisees-dans-le-cadre-de-soins-medicaux-ou-paramedicaux
     
    [5]           ANSM, « Logiciels et applications mobiles en santé », www.ansm.sante.fr, janv. 29, 2021. https://ansm.sante.fr/documents/reference/logiciels-et-applications-mobiles-en-sante (consulté le oct. 18, 2021).
     
    [6]           V. Boissart et al., « Groupe de travail AFIB 2019–2020 : sécurité numérique des équipements biomédicaux », IRBM News, vol. 42, no 1, p. 100298, févr. 2021, doi : 10.1016/j.irbmnw.2021.100298.
     
    [7]           HAS, « Guide sur les spécificités d’évaluation clinique d’un dispositif médical connecté (DMC) en vue de son accés au remboursement », HAS, Guide pratique 1, janv. 2019.
     
    [8]           ANSM, « L’ANSM lance une consultation publique sur un projet de recommandations pour la cybersécurité des dispositifs médicaux », ansm.sante.fr, oct. 16, 2020. https://ansm.sante.fr/actualites/lansm-lance-une-consultation-publique-sur-un-projet-de-recommandations-pour-la-cybersecurite-des-dispositifs-medicaux (consulté le oct. 18, 2021).
     
    [9]           « Directive 93/42/CEE du Conseil, du 14 juin 1993, relative aux dispositifs médicaux », Journal officiel de l’Union européenne, Document 31993L0042, Journal officiel n° L 169 du 12/07/1993 p. 0001-0043.
     
    [10]         « Directive 95/46/CE (annulé et remplacé par règlement Européen 679/2016) », ed. ec, www.ec.europa.eu, Directive.
     
    [11]         « Code de la santé publique », Ed. Legifrance, Paris, Version consolidée au 16 août 2020.
     
    [12]         G. Farges et al., Guide des bonnes pratiques de l’ingénierie biomédicale en établissement de santé, Les Pratiques de la Performance. Paris : Editions Lexitis, www.lespratiquesdelaperformance.fr, 2011. Consulté le : déc. 28, 2012.
     
    [13]         PGSSI-S, « Guide pratique - Régles pour les dispositifs connectés d’un systéme d’Information de santé », Ministère des affaires sociales et de la santé, Guide pratique V1, nov. 2013.
     
    [14]         « Norme ISO/IEC/IEEE 12207-2:2020 - Ingénierie des systèmes et du logiciel - Processus du cycle de vie du logiciel - Partie 2 : Relation et correspondance entre l’ISO/IEC/IEEE 12207:2017 et l’ISO/IEC 12207:2008 », Ed. Afnor, Paris, www.afnor.org, oct. 01, 2020. Consulté le : sept. 23, 2021.
     
    [15]         « Norme ISO/IEC/IEEE 15288:2015 - Ingénierie des systèmes et du logiciel - Processus du cycle de vie du système », Ed. Afnor, Paris, www.afnor.org, mai 15, 2015. Consulté le : sept. 23, 2021.
     
    [16]         « Norme NF EN 60601-1-8/A11 - Appareils électromédicaux - Partie 1-8 : exigences générales pour la sécurité de base et les performances essentielles - Norme collatérale : exigences générales, essais et guide pour les systèmes d’alarme des appareils et des systèmes électromédicaux », Ed. Afnor, Paris, www.afnor.org, avr. 21, 2018.
     
    [17]         « Norme NF EN 62366-1/A1 : 2020 », Ed. Afnor, Paris, www.afnor.org, aout 2020.
     
    [18]         « Norme NF EN ISO 13485- Dispositifs médicaux - Systèmes de management de la qualité - Exigences à des fins réglementaires », Ed. Afnor, Paris, www.afnor.org, avr. 30, 2016.
     
    [19]         « Norme NF EN ISO 14971 - Dispositifs médicaux - Application de la gestion des risques aux dispositifs médicaux », Ed. Afnor, Paris, www.afnor.org, déc. 18, 2019.
     
    [20]         « Norme NF ISO/IEC 25051 : 2014 - Ingénierie du logiciel - Exigences de qualité pour le logiciel et évaluation (SQuaRE) - Exigences de qualité pour les progiciels et instructions d’essai », Ed. Afnor, Paris, www.afnor.org, sept. 06, 2014. Consulté le : oct. 18, 2021.
     
    [21]         « Norme PR NF EN 62304 - Logiciels de santé - Processus du cycle de vie du logiciel - Projet de révision de la norme », ed. Afnor, Paris, www.afnor.fr, mars 12, 2021.
     
    [22]         « Règlement (UE) 2017/746 du Parlement européen et du Conseil du 5 avril 2017 relatif aux dispositifs médicaux de diagnostic in vitro et abrogeant la directive 98/79/CE et la décision 2010/227/UE de la Commission (Texte présentant de l’intérêt pour l’EEE. ) », Journal officiel de l’Union européenne, https://eur-lex.europa.eu, mai 2017.
     
    [23]         ANSM, « Exemples de logiciels et applications mobiles illustrant le positionnement réglementaire - ANSM », www.ansm.sante.fr, janv. 29, 2021. https://ansm.sante.fr/documents/reference/exemples-de-logiciels-et-applications-mobiles-illustrant-le-positionnement-reglementaire (consulté le oct. 18, 2021).
     
    [24]         HAS, « Évaluer les dispositifs médicaux connectés, y compris ceux faisant appel à l’intelligence artificielle », www.has-sante.fr, févr. 19, 2019. https://www.has-sante.fr/jcms/c_2905546/fr/evaluer-les-dispositifs-medicaux-connectes-y-compris-ceux-faisant-appel-a-l-intelligence-artificielle (consulté le oct. 18, 2021).
     
    [25]         Kevin Gutierrez, « Vers une nouvelle transition dans les dispositifs médicaux – Règlement (UE) 2017/745 », www.sante-digitale.fr, nov. 15, 2019. https://sante-digitale.fr/vers-une-nouvelle-transition-dans-les-dispositifs-medicaux-reglement-ue-2017745/ (consulté le oct. 05, 2021).
     
    [26]         ANAP - Appui Santé & Médico-Social, « Bloc opératoire - Optimiser les interfaces avec la pharmacie », anap.fr, janv. 06, 2016. https://ressources.anap.fr/bloc-operatoire/publication/1480-optimiser-les-interfaces-avec-la-pharmacie (consulté le oct. 18, 2021).
     
    [27]         GIP - CPage, « cpage », www.cpage.fr, 2018. https://www.cpage.fr/offre-globale.html (consulté le nov. 05, 2021).
     
    [28]         « Loi n° 2002-303 du 4 mars 2002 relative aux droits des malades et à la qualité du système de santé (1) », ed.legifrance, Paris, legifrance.fr, 2002‑303, févr. 2002. Consulté le : nov. 05, 2021.
     
    [29]         DCI - Cristal - Net, « DPI - Modules et fonctionnalités », Cristal. https://www.dcicristalnet.com/produit/modules-et-fonctionnalites (consulté le nov. 05, 2021).

    Annexe

    1. Annexe 1 : Mode d’emplois de la cartographie

    Mode d’emplois de la cartographie :

    Ce docu­ment a pour objec­tif de vous gui­der et vous pré­sen­ter le fonc­tion­ne­ment de la car­to­gra­phie inter­ac­tive du réseau.

    Intro­duc­tion

    La car­to­gra­phie a pour objec­tif de défi­nir les connexions entre les DM/DMC et logi­ciels connec­tés au sein d’un ser­vice de soin. Cela per­met­tra le main­tien effi­cace de la per­for­mance et la sécu­ri­té pour les patients.

    Les uti­li­sa­teurs de tels dis­po­si­tifs doivent être conscients des risques qui y sont asso­ciés mais aus­si savoir la res­pon­sa­bi­li­té qui leur incombe dans l’utilisation des don­nées four­nies. Avec cette car­to­gra­phie, il est plus facile de suivre le par­cours des don­nées et contac­ter la per­sonne adé­quate en cas de dysfonctionnement.

    Pour ce tra­vail, la car­to­gra­phie a été réa­li­sée pour un bloc opé­ra­toire de l'hôpital de Cha­lon sur Saône, mais elle peut être modi­fiée et mise à jour pour tout autre ser­vice de soins.

    Notice d’utilisation de la cartographie :

    Accueil avec les légendes, sym­bo­lique des icônes

    Il est pré­sen­té les acteurs, les types d’information et de connexion uti­li­sés pour la trans­mis­sion des données.

    2. Annexe 2 : La cartographie dans son ensemble

    Cette inter­face donne une vue glo­bale des élé­ments consti­tu­tifs de la car­to­gra­phie. Pour des infor­ma­tions sur les inter­ac­tions DM-PATIENT, il faut cli­quer sur le patient. Dans cette rubrique est sché­ma­ti­sé le type de DATA col­lec­té par le DM. Cli­quez sur l'icône  "flèche" pour retour­ner à la page pré­cé­dente ou sur l'icône  "mai­son"   pour retour­ner à la car­to­gra­phie principale.

     

    searchhomearrow-circle-left