Ce document date de juillet 2023, c'est tout de même assez étonnant qu'il faille attendre 18 mois et un lanceur d'alerte pour que soit révélé une exigence de porte cachée (qui ne semble pas évoqué dans ledit document).
Ce document ne semble mentionne pas de « triggers » (du moins sous ce nom) comme indiqué par le PP. Vu l’age qu’il a et son statut RC, ce ne serait pas très étonnant que la révision en cours d’écriture ajoute des exigences.
Cela dit, cette version vise déjà « l'envoi systématique et sécurisé dans Mon espace santé […] des documents de santé communiqués au patient » (certes avec la « non opposition [sic] du patient »), j’aimerais bien savoir ce qui peut faire fuiter plus de données.
Je travaille dans le milieu de l'interopérabilité des SI de santé et participe régulièrement aux ateliers ANS.
Je me suis créé un compte sur linuxfr pour pouvoir réagir.
Pour préciser le sujet, il s'agit de demander l'implémentation d'un système de récolte automatique des résultats de Tests Rapide d'Orientation Diagnostique (TROD) dans les logiciels des professionnels de santé concernés (ici les généralistes), en cas de crise sanitaire type COVID (état d'urgence), pour la surveillance épidémiologique.
Le système s'active via un fichier de config que le logiciel doit récupérer sur une URL fixée, sur un domaine de l'IGC Santé (l'état).
Le but est de simplifier et d'automatiser la récolte des résultats de tests sans intervention manuelle des professionnels de santé.
La transmission des résultats se fait par un envoi d'email par MSS (Messagerie Sécurisée de Santé), à une adresse gouvernementale, avec le résultat du test en pièce jointe.
Il est prévu que le patient et le professionnel soient informés de l'envoi mais ne puissent s'y opposer.
Le problème est à priori que la formulation des exigences laisse la possibilité d'imaginer que tout type de document pourrait être transmis automatiquement car les données à retourner sont indiquées dans le fichier de config.
Ceci, ajouté au fait qu'il n'est pas prévu de pouvoir débrayer l'envoi automatique a provoqué une réaction de certains PS qui considèrent cela comme une backdoor, même si ça n'en est pas une au sens strict car l'envoi n'est pas caché.
Mon avis perso est que ces exigences devraient être reformulées afin de ne pas permettre de mésusage potentiel de cette fonctionnalité, même si elle n'est censée être activée qu'en situation d'urgence sanitaire.
Reformuler une exigence est le processus normal d’une concertation SEGUR avec les acteurs concernés (ici les médecins). Le document n'est pas public justement, car il n’est pas dans sa version finale.
# Autres sources
Posté par Voltairine . Évalué à 5 (+4/-0).
C'est assez inquiétant si c'est avéré. Pour l'instant nous n'avons aucune autre source et l'article du PP est très succinct sur la technique et sur les possibilités de vérifier cette information.
Il faudrait éplucher le document de travail cité :
https://industriels.esante.gouv.fr/sites/default/files/media/document/DSR-MDV-LGC-Va2-Version_RC_JUILLET_2023.pdf
Ce document date de juillet 2023, c'est tout de même assez étonnant qu'il faille attendre 18 mois et un lanceur d'alerte pour que soit révélé une exigence de porte cachée (qui ne semble pas évoqué dans ledit document).
[^] # Re: Autres sources
Posté par Ltrlg . Évalué à 2 (+2/-0).
Ce document ne semble mentionne pas de « triggers » (du moins sous ce nom) comme indiqué par le PP. Vu l’age qu’il a et son statut RC, ce ne serait pas très étonnant que la révision en cours d’écriture ajoute des exigences.
Cela dit, cette version vise déjà « l'envoi systématique et sécurisé dans Mon espace santé […] des documents de santé communiqués au patient » (certes avec la « non opposition [sic] du patient »), j’aimerais bien savoir ce qui peut faire fuiter plus de données.
# Précisions
Posté par jbmerli . Évalué à 7 (+7/-0).
Bonjour,
Je travaille dans le milieu de l'interopérabilité des SI de santé et participe régulièrement aux ateliers ANS.
Je me suis créé un compte sur linuxfr pour pouvoir réagir.
Pour préciser le sujet, il s'agit de demander l'implémentation d'un système de récolte automatique des résultats de Tests Rapide d'Orientation Diagnostique (TROD) dans les logiciels des professionnels de santé concernés (ici les généralistes), en cas de crise sanitaire type COVID (état d'urgence), pour la surveillance épidémiologique.
Le système s'active via un fichier de config que le logiciel doit récupérer sur une URL fixée, sur un domaine de l'IGC Santé (l'état).
Le but est de simplifier et d'automatiser la récolte des résultats de tests sans intervention manuelle des professionnels de santé.
La transmission des résultats se fait par un envoi d'email par MSS (Messagerie Sécurisée de Santé), à une adresse gouvernementale, avec le résultat du test en pièce jointe.
Il est prévu que le patient et le professionnel soient informés de l'envoi mais ne puissent s'y opposer.
Le problème est à priori que la formulation des exigences laisse la possibilité d'imaginer que tout type de document pourrait être transmis automatiquement car les données à retourner sont indiquées dans le fichier de config.
Ceci, ajouté au fait qu'il n'est pas prévu de pouvoir débrayer l'envoi automatique a provoqué une réaction de certains PS qui considèrent cela comme une backdoor, même si ça n'en est pas une au sens strict car l'envoi n'est pas caché.
Mon avis perso est que ces exigences devraient être reformulées afin de ne pas permettre de mésusage potentiel de cette fonctionnalité, même si elle n'est censée être activée qu'en situation d'urgence sanitaire.
Reformuler une exigence est le processus normal d’une concertation SEGUR avec les acteurs concernés (ici les médecins). Le document n'est pas public justement, car il n’est pas dans sa version finale.
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.