IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Les données médicales de près de 500 000 patients français dérobées à des laboratoires
Ont été diffusées sur des forums de pirates informatiques

Le , par Stéphane le calme

223PARTAGES

15  0 
Libération a révélé ce mardi 22 février qu’un fichier constitué de données dérobées à des laboratoires et contenant l’identité complète de près d’un demi-million de Français, souvent accompagnée de données critiques, comme des informations sur leur état de santé ou même leur mot de passe, a circulé sur des forums de pirates informatiques.

Le fichier comporte 491 840 lignes, soit presque autant de patients identifiés avec, à chaque ligne, jusqu’à 60 informations sur la personne concernée. Numéro de sécurité sociale, date de naissance, groupe sanguin, adresse, médecin prescripteur, mais aussi des commentaires précisant l'état de santé, des traitements médicamenteux ou des pathologies (des commentaires comme « grossesse », « tumeur au cerveau », « séropositif HIV », « patiente sourde » ou encore «Levothyrox» et bien d’autres).

La façon dont le fichier est construit indique que les données proviennent de laboratoires de prélèvement médicaux et pas de cabinets médicaux ou d’hôpitaux. Selon les informations de Libération, les données proviennent principalement de cabinets médicaux des départements du Morbihan, de l’Eure, du Loiret et des Côtes-d’Armor. Selon la rubrique de vérification Checknews du quotidien Libération, qui a enquêté sur le sujet, les données proviendraient d'une trentaine de laboratoires de biologie médicale. Toujours selon Libération, les laboratoires touchés avaient tous utilisé le même logiciel de saisie de renseignements, qui a été progressivement abandonné.

La fuite de données aurait pu se produire lors de la migration de l’ancien logiciel vers le nouveau.

« Nous n'avons aucune certitude quant au fait que ce soit uniquement un logiciel Dedalus France qui est en cause dans cette affaire », a réagi auprès de l'AFP le directeur général délégué Didier Neyrat. « Nous avons mis en place une cellule de crise, car nous prenons cela au sérieux et nous allons travailler en partenariat avec nos clients pour comprendre ce qu'il s'est passé », a-t-il ajouté.

« On peut retrouver ce fichier à 7 endroits différents sur internet », a indiqué de son côté à l'AFP Damien Bancal, journaliste spécialiste de la cybersécurité, qui a le premier identifié la fuite le 14 février sur son blog Zataz.

Selon lui, ce fichier était l'objet d'une négociation commerciale entre plusieurs pirates sur un groupe Telegram spécialisé dans l'échange de bases de données volées et l'un d'entre eux l'a diffusé sur le web suite à une dispute. « 500 000 données, c'est déjà énorme et rien n'empêche de penser que les pirates en possèdent encore beaucoup plus », a-t-il déclaré à l'AFP.

D’après Libération, les données proviendraient de laboratoires, et auraient été collectées entre 2015 et 2020. La majorité d’entre elles datent de 2018 et 2019. Le journal relève que les laboratoires ont en point commun l’utilisation d’un même logiciel de saisie des renseignements médico-administratifs, développé par Dedalus France. Il ajoute que c’est également cette entreprise qui installe et maintient le parc informatique pour le compte des établissements.


Dedalus France avait déjà fait l'objet d'un billet en 2020. Jeudi 2 avril 2020, en plein confinement imposé par l'épidémie de Covid-19, un jeune développeur web employé par le groupe d'informatique hospitalier Dedalus est mis à pied à titre conservatoire et convoqué à un entretien préalable à un « éventuel » licenciement pour faute grave. Dans ce courrier, il lui est alors reproché des faits datant du 25 mars 2020.

Contacté par TICsanté, l'ex-développeur web de Dedalus a expliqué qu'à cette date, il avait déjà identifié une faille de sécurité importante dans le logiciel destiné aux laboratoires de biologie médicale KaliLab, pouvant « permettre d'accéder comme administrateur aux infrastructures informatiques de plus de 150 laboratoires d'établissements de santé ».

La porte d'entrée de ces serveurs pouvait être déverrouillée grâce à une clé privée de Dedalus... à laquelle il n'aurait pas dû avoir accès.

« Nous rappelons qu'en interne, l'accès à cette clé est réservé aux développeurs de l'intranet Dedalus Biologie. Cette clé a été récupérée sur une adresse URL précise et sans recherche préalable », a expliqué l'éditeur dans sa missive, se référant « à des traces d'accès » au serveur web prélevées le 25 mars « dès 13h26, soit 1h30 après que vous l'avez vous-même récupérée en votre qualité de développeur », reprochait-il à son salarié.

L'ex-développeur web s’est défendu : il a signalé cette faille en janvier 2020 et alerté à plusieurs reprises ses dirigeants français et même le PDG italien du groupe dès le début du mois de mars, avant de prévenir le fonctionnaire chargé de la sécurité des systèmes d'information (FSSI) du ministère des Solidarités et de la Santé, Philippe Loudenot, de cette faille importante et pouvant affecter le fonctionnement des établissements de santé clients, alors pleinement engagés dans la lutte contre l'épidémie de Covid-19.

Prenant l'alerte au sérieux, Philippe Loudenot va alors contacter la direction du groupe informatique dès le 26 mars pour leur confier la liste des éléments récupérés et les renseigner sur les établissements concernés par la faille et jugés vulnérables.

« Le groupe Dedalus a fait le nécessaire pour sécuriser ces accès et proposé une nouvelle version du logiciel. Nous avons eu un retour concernant cette montée de versions par la Société française d'informatique de laboratoire (SFIL) le 2 avril 2020 », a expliqué le FSSI dans un deuxième document.

«  Il n’y a pas de faille de sécurité et il n’y en a jamais eu », lançait alors Didier Neyrat, directeur général délégué de Dedalus France. Un mois et demi plus tard, en décembre 2020, TIC Santé à nouveau, exposait que Dedalus était victime d’une attaque rançongiciel. Mais encore une fois, Didier Neyrat rassurait : « A priori, il n’y a eu aucun vol de données et comme nous avons bloqué l’attaque, il n’y aura pas de paiement de rançon. »

Les attaques informatiques se multiplient actuellement contre les établissements de santé en France. Des pirates informatiques ont ainsi paralysé les hôpitaux de Dax et de Villefranche-sur-Saône les 8 et 15 février derniers.

Le 19 février, l'Agence du numérique en santé indiquait également sur son site qu'une liste de 50 000 identifiants de connexion d'agents de centres hospitaliers était en vente sur un forum cybercriminel. « Il y a eu 27 cyberattaques d'hôpitaux en 2020 et depuis le début de l'année 2021, c'est une attaque par semaine », relevait ainsi la semaine dernière le secrétaire d'État chargé du numérique, Cédric O. Cette recrudescence a amené le gouvernement à déployer de nouveaux budgets pour renforcer la sécurité de ces établissements.

Source : Libération

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de defZero
Membre extrêmement actif https://www.developpez.com
Le 24/02/2021 à 19:12
... Cette recrudescence a amené le gouvernement à déployer de nouveaux budgets pour renforcer la sécurité de ces établissements.
Voila, tout est dit. C'est une fois le mal fait que les décideurs bouge.
Par contre des principes de sécurités simple et pas cher comme la ségrégation des données et minimiser la collecte des données strictement nécessaires, c'est toujours pas assimilé on dirait.
Du coup, que des laboratoires stock numéro de sécu + Nom + Prénom + Date de naissance + groupe sanguin + adresse + médecin + commentaire, ça leurs sert à quoi exactement ?
Le numéro de sécu devrait leur suffire puisqu'il leur donne accès à tout le reste de façon indirecte et au besoin.
Le meilleur moyen d'exfiltrer des données, c'est bien de les copier partout pour rien.
Et puis bon, les commentaires sur l'état de santé des patient, ça na rien à foutre dans un laboratoire d' "analyse", comme la date de naissance ou autre, franchement un laboratoire d'analyse, ça analyse un prélèvement et pas autre chose.
10  2 
Avatar de kain_tn
Expert éminent https://www.developpez.com
Le 25/02/2021 à 9:59
Citation Envoyé par SQLpro Voir le message
J'ai déjà eu l'occasion de dire qu'en matière de sécurité des données, l'usage des outils "libre" que sont Linux, ou bien les bases de données "libres" que sont MySQL, MariaDB ou PostGreSQL sont de véritables passoires faciles à attaquer.

En effet, sous Linux, il est impossible de verrouiller les fichiers de données de la base contrairement à l'OS Windows. Le fait de verrouiller les fichiers empêche toute lecture, copie, ou modification de ces fichiers. Par exemple, les fichiers des bases Microsoft SQL Server sous Windows sont verrouillés ne peuvent pas être attaqués. Ceci est impossible sous Linux... Il est alors très facile, une fois le système pénétré, de voler ou modifier les fichiers des bases...

De plus, MySQL, MariaDB ou PostGreSQL ayant été développé avec un modèle de gestion du stockage des données qui confie à l'OS les accès aux fichiers, reproduit l'approche Linux sous Windows. Il en résulte le même problème sous Windows pour ces systèmes de bases de données.

Or que trouve t-on chez cet éditeur (Dedalus) ?
  • L'utilisation de Linux Debian comme OS
  • Une base de données Oracle
  • Des bases de données MySQL/MariaDB (pour la partie Web)

Bref toutes les passoires possibles !

De plus, le chiffrement des données dans les systèmes de bases de données que sont MySQL, MariaDB ou PostGreSQL n'est pas intégré à la base comme le font Oracle Database ou Microsoft SQL Server. Pour que le chiffrement des données fonctionne, il faut, dans MySQL, MariaDB ou PostGreSQL, à un moment donné, dans des fichiers côté serveur ou dans le code des applications, exposer la clé de chiffrement en clair. Ce n'est pas le cas dans Oracle ou SQL Server dont les clés de chiffrement sont stockées dans la base, masqués, chiffrées, et dépendante d'une hiérarchie de chiffrement qui remonte au moteur du SGBD, ce qui interdit le déchiffrement des données chiffrées si l'on ne peut reproduire l'ensemble de l'architecture de chiffrement depuis le plus haut niveau...

Dans les bases de données que sont MySQL, MariaDB ou PostGreSQL (pg_crypto) la sécurité du chiffrement est équivalente à celle d'une voiture fermée à clé, mais dont la clé serait laissée sur une des serrures de portière ! Bref, dans ces SGBDR, le chiffrement n'est que cosmétique et non réfléchis.

Dans toutes les récentes attaques, dans les hôpitaux, comme pour cet éditeur de solutions de laboratoires ont retrouve ces mêmes logiciels passoire !

Ajoutons à cela que le code source du logiciel libre étant disponible, il en plus facile d'en trouver les failles que celui dans celui des grands éditeurs qui ne le rende pas public.

Enfin, de récentes études ont montré que dans le libre, le nombre de bugs et de vulnérabilité était souvent beaucoup plus important que dans les systèmes de bases de données commerciaux, et la correction bien moins rapide...

Ceux qui ont prôné le logiciel libre sans en mesurer les conséquences ont une grave responsabilité dans ces affaires !
Bravo Sherlock! C'est vrai que SolarWinds, c'est arrivé sur du LInux avec du code libre et ouvert... Vous avez passé les derniers mois sans Internet???

Ce serait bien d'éviter de détourner le problème pour vendre votre tambouille: on ne devrait pas collecter et stocker plus de données que nécessaire. Des manières d'exfiltrer des données, il y en aura toujours, et si la DB est trop sécurisée eh bien les attaquants trouveront une faille dans les logiciels clients: ce ne sera ni la première fois, ni la dernière.
7  1 
Avatar de JCornat
Nouveau membre du Club https://www.developpez.com
Le 25/02/2021 à 11:24
"franchement un laboratoire d'analyse, ça analyse un prélèvement et pas autre chose."
Un laboratoire d'analyse ne fait pas qu'analyser les prélèvements, il y a systématiquement des médecins biologistes qui interprètent les résultats des analyses, pour prévenir au plus tôt les médecins / patients en cas de perturbations.
La date de naissance, le sexe, et même l'origine ethnique va influer sur les résultats.

"les commentaires sur l'état de santé des patient"
Là encore, les commentaires sont importants pour les futures interprétations des biologistes, leur permettant de contacter au mieux les médecins / patients

"Du coup, que des laboratoires stock numéro de sécu + Nom + Prénom + Date de naissance + groupe sanguin + adresse + médecin + commentaire, ça leurs sert à quoi exactement ? Le numéro de sécu devrait leur suffire puisqu'il leur donne accès à tout le reste de façon indirecte et au besoin."
Les laboratoires stockent toutes ces informations car il serait bien trop couteux en temps de requêter à l'assurance maladie dès que l'on souhaite afficher simplement un nom / prénom, sans compter les personnes qui n'ont pas de cartes vitale.
7  1 
Avatar de ARKHN3B
Nouveau membre du Club https://www.developpez.com
Le 24/02/2021 à 20:09
Citation Envoyé par defZero Voir le message
Du coup, que des laboratoires stock numéro de sécu + Nom + Prénom + Date de naissance + groupe sanguin + adresse + médecin + commentaire, ça leurs sert à quoi exactement ?
La donnée - et par conséquent l'enjeu de son exploitation - est le nouvel eldorado du 21ème siècle.

Si ils récupèrent autant d'informations, c'est qu'ils en font quelque chose derrière. Rappelons que le secteur de la santé est un secteur très lucratif...

Citation Envoyé par defZero Voir le message
C'est une fois le mal fait que les décideurs bouge
Comme partout malheureusement. .

Bien souvent, ces décideurs préfèrent attendre la/les conséquences à un problème - pleinement identifié - qu'ils auraient pu anticiper => "Mais c'est pas de notre faute, veuillez-nous croire. ". Et par expérience personnelle, pas besoin d'être dans une grosse entreprise pour retrouver ce genre de comportement...
5  0 
Avatar de Escapetiger
Expert éminent sénior https://www.developpez.com
Le 25/02/2021 à 15:08
Citation Envoyé par Stéphane le calme  Voir le message
Dedalus France avait déjà fait l'objet d'un billet en 2020. Jeudi 2 avril 2020, en plein confinement imposé par l'épidémie de Covid-19, un jeune développeur web employé par le groupe d'informatique hospitalier Dedalus est mis à pied à titre conservatoire et convoqué à un entretien préalable à un « éventuel » licenciement pour faute grave. Dans ce courrier, il lui est alors reproché des faits datant du 25 mars 2020.

Contacté par TICsanté, l'ex-développeur web de Dedalus a expliqué qu'à cette date, il avait déjà identifié une faille de sécurité importante dans le logiciel destiné aux laboratoires de biologie médicale KaliLab, pouvant « permettre d'accéder comme administrateur aux infrastructures informatiques de plus de 150 laboratoires d'établissements de santé ».

La porte d'entrée de ces serveurs pouvait être déverrouillée grâce à une clé privée de Dedalus... à laquelle il n'aurait pas dû avoir accès.
(.../...)

« Nous rappelons qu'en interne, l'accès à cette clé est réservé aux développeurs de l'intranet Dedalus Biologie. Cette clé a été récupérée sur une adresse URL précise et sans recherche préalable », a expliqué l'éditeur dans sa missive, se référant « à des traces d'accès » au serveur web prélevées le 25 mars « dès 13h26, soit 1h30 après que vous l'avez vous-même récupérée en votre qualité de développeur », reprochait-il à son salarié.

L'ex-développeur web s’est défendu : il a signalé cette faille en janvier 2020 et alerté à plusieurs reprises ses dirigeants français et même le PDG italien du groupe dès le début du mois de mars, avant de prévenir le fonctionnaire chargé de la sécurité des systèmes d'information (FSSI) du ministère des Solidarités et de la Santé, Philippe Loudenot, de cette faille importante et pouvant affecter le fonctionnement des établissements de santé clients, alors pleinement engagés dans la lutte contre l'épidémie de Covid-19.
(.../...)

«  Il n’y a pas de faille de sécurité et il n’y en a jamais eu », lançait alors Didier Neyrat, directeur général délégué de Dedalus France.
(.../...)

Donc, la branche française d'une société qui a 3 600 collaborateurs dans le monde, 1200 collaborateurs en R&D (cf. dedalus - a propos) tape allègrement sur un jeune développeur web qui découvre ce qu'on appelle une porte dérobée (backdoor), qui fait son devoir d'alerte, etc.

Tiens, en France, les «responsables mais pas coupables» ne changent pas beaucoup; ça me rappelle Serge Humpich * dans les années 90 avec le GIE Cartes Bancaires.

Particulièrement intéressé par l'enquête et les éventuelles suites judiciaires pour le développeur et le patron...

*
[Edit]
En 1997, il met en évidence une faille dans le système de sécurité des cartes bancaires. Cette faille permet de créer des cartes acceptées par les terminaux, mais non liées à un compte bancaire.

Épaulé par un avocat, il tente – sans succès – de négocier[réf. nécessaire] son « savoir-faire » auprès du GIE des cartes bancaires. Pour démontrer la faisabilité de cette technique, il effectue une démonstration publique de la vulnérabilité des cartes en retirant un carnet de tickets de métro au moyen d'une carte de sa fabrication dans un distributeur automatique. Cette tentative lui vaut une perquisition, la saisie de son matériel et une mise en garde à vue.

Il est jugé le 25 février 2000, « coupable de falsification de cartes bancaires et d'introduction frauduleuse dans un système automatisé de traitement ». Et cela, malgré de nombreux soutiens envers son geste, qui a mis en évidence des failles techniques et de conception à corriger dans ces cartes bancaires. Il est condamné à 10 mois de prison avec sursis et s'est ensuite désisté de la procédure d'appel qu'il avait lui-même engagée. À l'issue de cette condamnation, il écrit un livre, Le cerveau bleu, pour relater sa version de l'affaire.

Ensuite, il fonde une entreprise aux États-Unis et quelques années plus tard, revient en France où il travaille pour la société Bearstech

5  0 
Avatar de JCornat
Nouveau membre du Club https://www.developpez.com
Le 25/02/2021 à 11:46
Citation Envoyé par kain_tn Voir le message
Soit. Donc pour "gagner du temps" ils stockent des infos dont ils n'ont pas besoin. Et voilà le résultat...
Ce n'est pas uniquement pour "gagner du temps", c'est que ce n'est tout simplement pas envisageable techniquement de ne rien stocker.
Que faire dans le cas d'un enfant qui a le même numéro que son parent ?
Sans stocker ni sa date de naissance, ni son sexe, ni son nom, ni rien à part son numéro qui n'est donc pas unique, les biologistes se retrouveraient avec un tube analysé sans aucun contexte, et c'est le contexte qui fait la pertinence du résultat.
5  1 
Avatar de nickylarson
Membre habitué https://www.developpez.com
Le 25/02/2021 à 23:34
Citation Envoyé par SQLpro Voir le message
J'ai déjà eu l'occasion de dire qu'en matière de sécurité des données, l'usage des outils "libre" que sont Linux, ou bien les bases de données "libres" que sont MySQL, MariaDB ou PostGreSQL sont de véritables passoires faciles à attaquer.

En effet, sous Linux, il est impossible de verrouiller les fichiers de données de la base contrairement à l'OS Windows. Le fait de verrouiller les fichiers empêche toute lecture, copie, ou modification de ces fichiers. Par exemple, les fichiers des bases Microsoft SQL Server sous Windows sont verrouillés ne peuvent pas être attaqués. Ceci est impossible sous Linux... Il est alors très facile, une fois le système pénétré, de voler ou modifier les fichiers des bases...

De plus, MySQL, MariaDB ou PostGreSQL ayant été développé avec un modèle de gestion du stockage des données qui confie à l'OS les accès aux fichiers, reproduit l'approche Linux sous Windows. Il en résulte le même problème sous Windows pour ces systèmes de bases de données.

Or que trouve t-on chez cet éditeur (Dedalus) ?
  • L'utilisation de Linux Debian comme OS
  • Une base de données Oracle
  • Des bases de données MySQL/MariaDB (pour la partie Web)

Bref toutes les passoires possibles !

De plus, le chiffrement des données dans les systèmes de bases de données que sont MySQL, MariaDB ou PostGreSQL n'est pas intégré à la base comme le font Oracle Database ou Microsoft SQL Server. Pour que le chiffrement des données fonctionne, il faut, dans MySQL, MariaDB ou PostGreSQL, à un moment donné, dans des fichiers côté serveur ou dans le code des applications, exposer la clé de chiffrement en clair. Ce n'est pas le cas dans Oracle ou SQL Server dont les clés de chiffrement sont stockées dans la base, masqués, chiffrées, et dépendante d'une hiérarchie de chiffrement qui remonte au moteur du SGBD, ce qui interdit le déchiffrement des données chiffrées si l'on ne peut reproduire l'ensemble de l'architecture de chiffrement depuis le plus haut niveau...

Dans les bases de données que sont MySQL, MariaDB ou PostGreSQL (pg_crypto) la sécurité du chiffrement est équivalente à celle d'une voiture fermée à clé, mais dont la clé serait laissée sur une des serrures de portière ! Bref, dans ces SGBDR, le chiffrement n'est que cosmétique et non réfléchis.

Dans toutes les récentes attaques, dans les hôpitaux, comme pour cet éditeur de solutions de laboratoires ont retrouve ces mêmes logiciels passoire !

Ajoutons à cela que le code source du logiciel libre étant disponible, il en plus facile d'en trouver les failles que celui dans celui des grands éditeurs qui ne le rende pas public.

Enfin, de récentes études ont montré que dans le libre, le nombre de bugs et de vulnérabilité était souvent beaucoup plus important que dans les systèmes de bases de données commerciaux, et la correction bien moins rapide...

Ceux qui ont prôné le logiciel libre sans en mesurer les conséquences ont une grave responsabilité dans ces affaires !
Réduire ce problème de «*piratage*» a du SQLserver/Win vs Mysql/PostgreSQL etc c’est vraiment n’importe quoi.

Je vais forcer le trait «*à peine*» . L’avenir (Et déjà le présent en réalité) des base de données c’est le cloud et le cloud orienté Linux et consort donc parler de Windows qui est perfusé à cous de Linux avec WSL ... je ne suis pas anti Windows par ailleurs même si je suis passé sur Mac 💻 , j’ai toujours un xps 13 .

L’avenir et le présent c’est les micro-service, des fonction dans le cloud et des bases qui sont auto gérées et propose / suggèrent des index toutes seules avec beaucoup d’optimisation qui nous facilitent la vie...

Le fait que tel ou tel base ne propose pas tel chiffrement alors que SQLserver le fait bof , ce n’est pas significatif. Quand je veux faire quelque chose de pointu en chiffrement, j’utilise la lib, le composant qui va bien , je le développe ou fait appel à un spécialiste...le jour où le chiffrement est mort , on update que le composant en question et c’est très bien comme ça.
Ça me rappelle quand j’ai vu les bdd générer du html avec des commande SQL... beurk 🤮

Le fond du problème est simple , l’informatique des hôpitaux est une passoire, je parle en connaissance de cause puisque ayant conduit dès projet dans le domaine ch publique ou centre de recherche privé plein d’argent.
Mot de passe admin de bdd facilement accessible et avec full access sans trop chercher. Ça c’est le premier point.

Le deuxième c’est l’incompétence : quand tu vois que la plupart des gens de l’informatique viennent historiquement du service cuisine... Des gens qui ne savent pas découper correctement un hprim / Xml ,
qu’on vire l’admin Oracle parce que elle sert à rien...

y a aussi les DSI qui font en sorte de maintenir un système merdique pour se rendre utile...🤔 et qui ne connaissent rien à un SIH ni à la sécurité sur le plan technique de l’authentification d’une application à base de token... 😱

Je ne parle pas ds copies de bases de données en partage et des archives pst oubliés sur le reseau... même les partage masques sous Windows étaient inconnus de la DSI....

Bref j’arrête. J’ai encore des potes qui gravitent là dedans et ça n’a pas changé... 😥

Quand au budget, c’est pas le principal problème, c’est l’utilisation qui en est fait. Répondre à un appel à projet pour toucher un maximum de pognon de l’état pour en utiliser 35% et le reste sur d’autres poste de dépense, c’est un sport national...
4  0 
Avatar de kain_tn
Expert éminent https://www.developpez.com
Le 24/02/2021 à 20:20
Citation Envoyé par defZero Voir le message
Voila, tout est dit. C'est une fois le mal fait que les décideurs bouge.
Par contre des principes de sécurités simple et pas cher comme la ségrégation des données et minimiser la collecte des données strictement nécessaires, c'est toujours pas assimilé on dirait.
Ah non mais là ce n'est pas la sécurité des données qui les intéresse mais "celle des établissements" (pour citer l'article) !

On parle d'un état dont les gouvernements successifs ont pour lubie la création "de fichiers", comme ils disent (https://fr.wikipedia.org/wiki/Fichage_en_France), et la centralisation des données... Comme tu le dis, minimiser la collecte de données n'est pas assimilé

Citation Envoyé par ARKHN3B Voir le message
La donnée - et par conséquent l'enjeu de son exploitation - est le nouvel eldorado du 21ème siècle.
Si ils récupèrent autant d'informations, c'est qu'ils en font quelque chose derrière. Rappelons que le secteur de la santé est un secteur très lucratif...
Comme ça au pif, je dirais que le "quelque chose derrière" c'est de revendre les infos aux assurances (santé, vie, etc.) et assimilées. On peut même imaginer la revente à des services RH pour leur permettre de faire de la discrimination en n'embauchant que des employés "aptes" (comprendre avec le moins d'absences/arrêts/maternité possibles).

Ce n'est, bien entendu, que pure spéculation de ma part, même si comme il y a beaucoup d'argent en jeu, je ne suis peut-être pas très loin de la réalité. Qu'est-ce que vous pensez qu'ils peuvent bien faire de ces données, vous?
3  0 
Avatar de
https://www.developpez.com
Le 25/02/2021 à 9:15
J'ai comme l'impression qu'une peine de prison pour le DSI responsable ainsi que pour les éventuels sous traitants réduirait drastiquement le nombre de vols de données. Actuellement, la sécurité n'est vue que comme un coût inutile. Le jour où il y aura des morts, les choses évolueront peut-être
3  0 
Avatar de tourlourou
Modérateur https://www.developpez.com
Le 25/02/2021 à 14:52
Citation Envoyé par JCornat Voir le message
"franchement un laboratoire d'analyse, ça analyse un prélèvement et pas autre chose."
Un laboratoire d'analyse ne fait pas qu'analyser les prélèvements, il y a systématiquement des médecins ou pharmaciens biologistes qui interprètent les résultats des analyses, pour prévenir au plus tôt les médecins et autres prescripteurs / patients en cas de perturbations.
La date de naissance, le sexe, et même l'origine ethnique va influer sur les résultats. sur leurs intervalles de référence, plutôt

"les commentaires sur l'état de santé des patient"
Là encore, les commentaires sont importants pour les futures interprétations des biologistes, leur permettant de contacter au mieux les médecins / patients

"Du coup, que des laboratoires stock numéro de sécu + Nom + Prénom + Date de naissance + groupe sanguin + adresse + médecin + commentaire, ça leurs sert à quoi exactement ? Le numéro de sécu devrait leur suffire puisqu'il leur donne accès à tout le reste de façon indirecte et au besoin."
Les laboratoires stockent toutes ces informations car il serait bien trop couteux en temps de requêter à l'assurance maladie dès que l'on souhaite afficher simplement un nom / prénom, sans compter les personnes qui n'ont pas de cartes vitale.
Bonjour,

JCornat a raison (quelques précisions en rouge), tandis que defZero a une vision passéiste et inexacte de la profession. En Europe, la biologie a simultanément évolué vers l'industrialisation de l'acte d'analyse et la médicalisation pour son interprétation.
Nous avons besoin de données d'état-civil, administratives et médicales, sans compter celles que nous produisons et devons conserver un temps minimal, précieuses aux fins de comparaison, suivi d'évolution, etc.

Se fier à un numéro sécu pour récupérer des infos d'état-civil est utopique en termes de temps. Et quant à leur fiabilité (j'ai conscience que leur collecte in-situ est sujette à problèmes aussi !) et aux délais pour faire corriger à la CPAM un prénom mal orthographié (Simonnne) ou lorsqu'une assurée souhaite reprendre son nom de naissance après séparation... Des évolutions viendront, cependant.

Nous sommes aussi tributaires d'échanges avec des organismes, sous des formats imposés, parfois archaïques (résultats, facturations, statistiques Covid, etc.) et l'efficacité est d'utiliser des données collectées une fois (malheureusement, pas toujours en une seule fois...) plutôt que de les récupérer à la demande de nombreuses fois.

[EDIT]
Citation Envoyé par kain_tn
On ne dit pas qu'il ne faut rien stocker, mais uniquement le strict nécessaire.
Ce qui fait beaucoup : état-civil, adresse (on poste encore des résultats, et on a parfois besoin d'envoyer le SAMU pour un résultat critique chez un patient injoignable), téléphone (pour communiquer au plus vite un résultat ou obtenir les renseignements indispensables si le prélèvement s'est fait en dehors du laboratoire), données de traitements nécessaires en cas de dosages de médicaments, etc.

La biologie est médicale, ne pouvant donc se concevoir sans contextualisation pour son interprétation, et accréditée dans un cadre strict (NF/ISO 15189) avec un Guide technique d'accréditation pour l’évaluation des systèmes informatiques en biologie médicale à respecter.
3  0