Pseudonymisation et anonymisation (plate-forme eHealth)

La Plate-forme eHealth met à la disposition de ses partenaires des services qui convertissent des données à caractère personnel relatives à la santé en données codées ou anonymes, dont l'identité du patient ou du prestataire de soins ne peut être déduite ni directement ni indirectement^[1][2]. Le Welcome Pack compte « pseudonymisation et anonymisation » parmi les services de base (voir Services de base de la plate-forme eHealth)^[3].

La famille comprend :

• Seals (SOAP) : le web service Seals (anciennement Codage v2) succède à Codage v1 et code et décode des données dans un contexte médical (cookbook v2.2 du 06/07/2022)^[4]. Selon le catalogue de production, Seals code et décode des chaînes de caractères quelconques, la clé restant auprès de la plate-forme eHealth et les données chiffrées chez l'appelant^[5].
• Batch codage : la plate-forme eHealth agit comme trusted third party (TTP) pour le codage et le décodage de données de santé pour le compte d'un partenaire^[2].
• Anonymisation : irréversible, avec l'intervention d'un TTP^[2].
• Blinded pseudo (REST, « Pseudonymisation ») : le catalogue de production mentionne le service REST Pseudonymisation pour pseudonymiser, identifier ou convertir un identifiant^[5]. Blinded pseudo n'est, strictement parlant, pas un service de base mais un service dérivé qui répond aux mêmes normes de qualité et de sécurité que les services de base de la loi eHealth^[1].

Quel problème résout-il ?

Les services permettent de traiter ou de partager des données de santé sans que le destinataire connaisse l'identité du patient^[1]. Blinded pseudo adapte les pseudonymes par partie traitante sans dépseudonymiser les données^[2] : le service génère un pseudonyme différent par domaine métier^[6] et prend en charge la conversion d'un pseudonyme aveuglé vers un domaine cible^[6]. Le propriétaire du domaine ne voit que le pseudonyme de son domaine et non l'identité du patient^[6].

Statut : production. La plate-forme eHealth fournit ces services^[1]. Applications dans les sources traitées :

• UHMEP : depuis la release R20251 (15/04/2025), UHMEP pseudonymise, outre le numéro d'identification de la sécurité sociale, aussi l'information textuelle du patient et destinée au patient dans une prescription médicale, via le service Pseudo REST^[7]. Pour le statut d'UHMEP (phases de test et de pilote), voir UHMEP et la prescription de renvoi électronique (eReferral).
• Recip-e : le cookbook FHIR décrit l'utilisation du service de pseudonymisation pour pseudonymiser, convertir et identifier des données^[8].
• Vitalink : dans l'environnement FHIR de Vitalink, les données à caractère personnel sont pseudonymisées via le service de pseudonymisation de la plate-forme eHealth^[9]. Pour Vitalink 2.0, la ministre décrit un modèle dans lequel le numéro de registre national est remplacé par un pseudonyme et où les données de santé restent lisibles^[10].
• RN Consult : pour PseudoPersonService, le numéro d'identification de la sécurité sociale ou le numéro BIS doit avoir été pseudonymisé au préalable via le service de pseudonymisation^[11].
• Rapportage épidémiologique de laboratoire : selon la description du flux dans une délibération, l'identification du patient (NISS) est pseudonymisée via la plate-forme eHealth (« codage eHBox ») avant que les données n'aboutissent dans le datawarehouse de healthdata.be^[12] (voir HD4DP v2 (healthdata.be)). Hypothèse : il s'agit d'un service de cette famille ; la source ne dit pas lequel.

Le Data Attribute Service (DAAS) a lui aussi été rendu pseudo-compatible^[11] (voir Services de base de la plate-forme eHealth).

Services et interfaces techniques

• Pseudonymisation REST : pour appeler le service, il faut un client I.AM Connect qui obtient un access token (JWT)^[6].
• Aveuglement du côté du client : selon la documentation d'une bibliothèque d'aide open source distincte, de Smals, le service de pseudonymisation n'échange que des points de courbe elliptique ; le client convertit un numéro d'identification du patient (NISS) en un tel point et l'aveugle avant l'appel, de sorte que le service lui-même ne voit aucun identifiant de patient^[13][13].
• Seals : la clé reste auprès de la plate-forme eHealth, les données chiffrées chez l'appelant^[5].

API dans le catalogue de la plate-forme eHealth

État du catalogue au 28/09/2026 (registre de l'Atlas). Le catalogue de production décrit les deux services^[5][5].

• Seals (anciennement Codage v2) succède à Codage v1^[4] ; aucune date de retrait de Codage v1 n'a été trouvée.
• Version R20251 (15/04/2025) : extension de l'utilisation par UHMEP aux informations textuelles contenues dans les prescriptions^[7].
• Aucune feuille de route n'a été trouvée pour les services eux-mêmes.
• La note 26/116 du Comité de sécurité de l'information (2 juin 2026) traite des principes généraux du traitement, de la pseudonymisation et de la répartition des rôles dans le cadre de l'utilisation secondaire, en particulier pour la Plate-forme eHealth et l'Agence des données de santé^[14]. Lors du couplage de sources, un tiers de confiance (TTP) est toujours sollicité^[14] ; la Plate-forme eHealth n'a pas accès aux données de santé et intervient comme TTP de codage^[14]. L'Agence des données de santé ne dispose pas encore d'une base légale explicite pour agir comme TTP autonome ; dans l'attente d'une modification législative en préparation, la Plate-forme eHealth peut également être responsable du traitement pour la deuxième étape de pseudonymisation, l'Agence des données de santé agissant comme sous-traitant^[14][14]. Ni la Plate-forme eHealth ni l'Agence des données de santé ne peuvent elles-mêmes traiter, en qualité de responsables du traitement, des données destinées à une utilisation secondaire^[14].

• Obligation : pour les services de pseudonymisation (WS Seals, Batch codage, Blinded pseudo) et pour l'anonymisation, un accord du Comité de sécurité de l'information est obligatoire^[1][3][3].
• Utilisation indirecte : UHMEP, Recip-e FHIR et l'environnement FHIR de Vitalink reposent sur des pseudonymes^[7][8][9]. Interprétation : les logiciels hospitaliers entrent donc aussi en contact avec la pseudonymisation via ces services.
• Recommandation (propre) : pour chaque nouveau projet d'enregistrement ou d'utilisation secondaire, vérifier si le destinataire attend un numéro d'identification de la sécurité sociale pseudonymisé, quel service (Seals ou Blinded pseudo) est prévu à cet effet et s'il existe une délibération du Comité de sécurité de l'information.

Conditions d'implémentation et limites

Après un accord du Comité de sécurité de l'information, les services de pseudonymisation requièrent un certificat eHealth et l'implémentation d'un service de chiffrement^[1]. Pour le service REST, un client I.AM Connect est en outre requis^[6].

• Service de base ou service dérivé : le Welcome Pack qualifie la pseudonymisation de service de base^[3], alors que Blinded pseudo est, selon la même famille de sources, strictement parlant un service dérivé^[1]. Interprétation : pas de véritable contradiction ; Blinded pseudo est un service dérivé qui suit les mêmes normes que les services de base.
• Dénomination : « Seals », « Codage v2 », « Pseudo REST », « Pseudonymisation » et « Blinded pseudo » sont utilisés indifféremment ; dans le catalogue, les API s'appellent « Seals » et « Pseudonymisation ».
• Codage v1 : statut non trouvé (lacune).