Auteurs

Contacts

• Maria­na Alva­rez :
• Julien Char­ton :
• Jor­dy Ramos :
• Alexan­dra Laurent :
• Adé­bo­la Fatoke :

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

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­toire	Volon­taire	Guides
Règle­ment euro­péen 2017/745 rela­tif aux DM	NF 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 DMDIV	Normes ISO/CEI 12207 et ISO/CEI 15288 : Cycle de vie des sys­tèmes et du logiciel	Art 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 personnelles	NF 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 DIV	Cer­ti­fi­ca­tion NF - Logi­ciel par l’AFNOR
	NF EN 62366 : Apti­tude à l’utilisation des DM ou DM DIV	Recom­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, n^o 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.