Questions fréquentes

Oui, en l’état du DSR, l’exigence SC/DMP/UX.46 ne prévoit pas de limitation explicite d’antériorité. 
Toutefois, des pistes ont été évoquées, notamment : 

• une limitation temporelle (ex. derniers mois), 
• un déclenchement conditionné à une action utilisateur (consultation explicite du DMP). 

Ces pistes ne sont pas actées à ce stade, mais peuvent être étudiées sur la base de retours éditeurs argumentés. 

Oui. 
Les exigences affichées dans Convergence sont générées automatiquement en fonction : 

• des profils fonctionnels déclarés, 
• des composants optionnels sélectionnés. 

Une exigence non visible dans Convergence n’est pas attendue pour le périmètre déclaré. 

Le DSR Vague 2 Médecine de ville n’a pas vocation à être republié. 
Toutefois, des ajustements ciblés peuvent être étudiés lorsque des difficultés techniques ou fonctionnelles sont objectivées et documentées par les éditeurs (ex. impacts de performance, volumétrie, faisabilité). 
Ces ajustements concernent uniquement des exigences identifiées et ne remettent pas en cause la structure globale du référentiel. 

Non, la conservation des justificatifs d’identité INS n’est pas requise. Il n’existe aucune obligation de les stocker, conformément au principe de simplification prévu par le RGPD.

Oui : le chiffrement n'a pas d'impact sur l'obligation de certification. La nature de la donnée de santé à caractère personnel n'est pas modifiée.

Oui, l'utilisation d'un code d'une nomenclature au lieu d'un libellé n'a pas d'impact sur l'obligation de certification. La nature de la donnée de santé à caractère personnel n'est pas modifiée.

L’obligation de disposer d’un certificat de conformité mentionnée à l’article L.1111-8 du code de la santé publique s’applique à toute entité qui propose un service d’hébergement

1. portant sur des données de santé à caractère personnel recueillies à l'occasion d'activités de prévention, de diagnostic, de soins ou de suivi social et médico-social.
2. pour le compte du patient ou pour le compte des professionnels de santé, des établissements et services de santé et tout autre organisme réalisant des missions de prévention, de soins, de suivi médico-social et social à l’origine de ces données.

Ces conditions sont cumulatives et l'obligation s'applique à toute personne (physique ou morale), qu’elle relève du droit public ou du droit privé. 

Tout professionnel de santé, tout établissement et service de santé et tout autre organisme réalisant des missions de prévention, de soins, de suivi médico-social et social (personnes physiques ou morales) doit apprécier au cas par cas si ces données de santé dont il entend confier l’hébergement à un tiers proviennent de son activité de prévention, de diagnostic, de soins ou de suivi social et médico-social. 

En outre, tout projet de système d’information (SI) portant sur l’exploitation des données susmentionnées nécessite de s’interroger au cas par cas sur l’application de la législation relative à l’hébergement des données de santé. Il incombe donc au responsable du système d’information de veiller au respect de cette législation dès que l’une des fonctionnalités du SI concerne des données de santé répondant aux critères ci-dessus.

Par exemple, un établissement de santé exploitant un DPI est tenu de recourir à un hébergeur certifié HDS en cas d’externalisation de l’hébergement de ce DPI.

Le règlement européen sur la protection des données personnelles donne une définition depuis avril 2016. Ce sont les données relatives à la santé physique ou mentale d'une personne physique, y compris la prestation de services de soins de santé, qui révèlent des informations sur l'état de santé de cette personne.

Des précisions sont apportées par la CNIL en suivant ce lien : https://www.cnil.fr/fr/quest-ce-ce-quune-donnee-de-sante

Il résulte d’une interprétation des textes réalisée par le ministère chargé de la santé que les Groupements hospitaliers de territoire peuvent être exemptés de l’obligation de certification HDS s’ils respectent les trois conditions cumulatives décrites ci-après.

• La convention GHT doit prévoir explicitement la délégation d’activité d’hébergement à l’établissement hébergeur (cet établissement hébergeur peut être l’établissement support du GHT et/ou tout autre établissement membre du GHT en accord toutefois avec l’établissement support qui doit assurer la gestion commune du système d’information). En effet, dans une telle hypothèse, l’ensemble des établissements parties à la convention GHT peuvent être considérées comme co-responsables de traitement au sens du RGPD. Autrement dit, l’établissement hébergeur du GHT est exempté de l’obligation de certification HDS si et seulement si la convention constitutive du GHT établit la co-responsabilité et lui en confie l’hébergement.
• En outre, un accord de co-responsabilité de traitement doit être conclu entre l’ensemble des membres du GHT, conformément aux dispositions de l’article 26 du RGPD.  Si les modalités pratiques de cette délégation peuvent être prévues dans le règlement intérieur du GHT, elles doivent être détaillées dans une convention de co-traitance qui répartit les rôles et responsabilités de chacun. La co-responsabilité de traitement implique qu’en cas de manquements aux dispositions du RGPD sur l’activité d’hébergement, l’ensemble des membres du GHT sont susceptibles de voir leur responsabilité engagée.
• Enfin, des mesures doivent être prises pour assurer la sécurité et la confidentialité des données hébergées ainsi que, d’une manière plus générale, le respect du RGPD. Pour rappel, un palier de sécurité dit « hébergement de données de santé » est défini dans le cadre du dispositif de certification SI. L’établissement hébergeur peut garantir ce palier de sécurité soit en recourant à un hébergeur externe de données de santé certifié HDS, soit en assurant lui-même la conformité requise.

Oui, la pseudonymisation n'a pas d'impact sur l'obligation de certification. La nature de la donnée de santé à caractère personnel n'est pas modifiée.