HDS et RGPD : deux obligations distinctes qui se cumulent

« On est conformes RGPD, donc on est bons sur les données de santé. » Cette phrase, entendue à chaque cadrage ou presque, mélange trois régimes distincts. Les démêler prend cinq minutes et évite des mois de reprise.

Trois questions, trois régimes

Régime	Question à laquelle il répond	Ce qu’il ne couvre pas
RGPD	Avez-vous le droit de traiter ces données, et comment les protégez-vous ?	Le fait que l’hébergeur soit certifié
Article L.1111-8 (HDS)	L’entité qui héberge ces données est-elle certifiée pour cela ?	La licéité de votre traitement
PGSSI-S	Votre système d’information respecte-t-il les exigences de sécurité du secteur ?	Le statut réglementaire de votre logiciel

Aucun ne se substitue aux autres. Un projet peut être irréprochable sur le RGPD et en infraction sur le HDS ; l’inverse est tout aussi possible.

Ce que le RGPD impose spécifiquement

Les données concernant la santé relèvent des catégories particulières de données au sens du RGPD. Leur traitement est en principe interdit, sauf à relever d’une exception : consentement explicite, médecine préventive ou du travail, gestion des services de santé, motifs d’intérêt public en santé publique, recherche.

Cette qualification a trois conséquences pratiques :

Une base légale à identifier explicitement. Beaucoup de projets se reposent sur le consentement par défaut, alors qu’une autre exception est souvent plus solide — et moins fragile, un consentement pouvant être retiré.

Une analyse d’impact. Le traitement de données de santé à grande échelle figure parmi les cas appelant une analyse d’impact relative à la protection des données. Elle n’a d’intérêt que menée assez tôt pour orienter l’architecture.

Les référentiels et méthodologies de référence de la CNIL. La CNIL publie des cadres sectoriels auxquels un responsable de traitement peut déclarer se conformer, ce qui allège ses formalités. La MR-004 couvre notamment les recherches n’impliquant pas la personne humaine, les études et évaluations dans le domaine de la santé. Y adhérer suppose de respecter l’intégralité du cadre.

La frontière de la donnée de santé, en pratique

C’est là que les projets se trompent. Une donnée de santé n’est pas seulement une donnée médicale explicite : ce sont aussi les données qui révèlent un état de santé.

Sont donc concernés, souvent à la surprise des équipes : le motif d’une prise de rendez-vous, la spécialité du praticien consulté, une liste de médicaments, une donnée d’activité physique interprétée dans un contexte de suivi, un simple horodatage de connexion à un service dédié à une pathologie.

Cette qualification commande à la fois le régime RGPD et l’obligation d’hébergement. C’est pourquoi elle doit être faite en premier, et par écrit.

Ce que ni le RGPD ni le HDS ne couvrent

La sécurité de votre application. Ni un certificat HDS ni un registre de traitements conforme ne disent quoi que ce soit de la robustesse de votre authentification, de la finesse de vos habilitations, de la qualité de votre journalisation ou de votre capacité à démontrer qui a fait quoi.

C’est l’objet de la PGSSI-S, dont une partie du corpus est opposable — et c’est le régime que les projets découvrent en dernier, généralement au premier audit client sérieux.

L’ordre dans lequel traiter les trois

1. Qualifier les données — sont-elles des données de santé, et dans quel contexte ont-elles été recueillies ? Cette réponse conditionne les deux régimes suivants.
2. Établir la base légale et l’analyse d’impact, assez tôt pour qu’elles influencent l’architecture plutôt que de la constater.
3. Trancher l’obligation d’hébergement et choisir entre certification propre et hébergeur certifié.
4. Traiter la sécurité applicative en continu, sur toute la durée du projet.

Fait dans cet ordre, l’ensemble représente quelques jours de cadrage. Fait dans le désordre, chaque étape invalide les précédentes.