Entrepôts de données de santé (EDS) et Health Data Hub : architecture des pipelines pour la recherche

Réponse directe

Un entrepôt de données de santé (EDS) hospitalier rassemble les données du DPI, du PMSI, de la biologie et des comptes rendus pour la recherche. En France, il se constitue sous le référentiel CNIL de 2021 (simple déclaration de conformité s'il repose sur une mission d'intérêt public) ou sur autorisation, et chaque projet qui l'exploite relève de sa propre formalité. Le Health Data Hub, juridiquement la Plateforme des données de santé (PDS), est le guichet d'accès au SNDS ; il quitte Microsoft Azure pour Scaleway, retenu en avril 2026, avec une migration annoncée entre fin 2026 et début 2027. Côté technique, le schéma qui tient : ingestion par source, pseudonymisation dès l'entrée, normalisation OMOP, espaces projets cloisonnés.

Deux objets à ne pas confondre : l'EDS et le SNDS

Un EDS appartient à un établissement ou à un groupement. Le SNDS est une base nationale médico-administrative. Les pipelines, les règles d'accès et la granularité des données n'ont rien à voir.

Le site du SNDS détaille ses composantes : les trois bases historiques, l'intégration prévue de données médico-sociales issues des MDPH et d'un échantillon de données des organismes complémentaires, et une durée de conservation de dix-neuf ans en plus de l'année de recueil, suivie d'une période d'archivage.

Côté établissements, l'AP-HP a été pionnière : son entrepôt a obtenu en janvier 2017 la première autorisation CNIL accordée à un EDS et agrège les données de ses 38 hôpitaux. D'autres CHU ont suivi ; beaucoup sont aujourd'hui en phase de passage à l'échelle plutôt que de création.

Le cadre réglementaire, vu depuis le pipeline

Constitution de l'entrepôt. La CNIL a adopté un référentiel sur les entrepôts de données de santé (délibération n° 2021-118 du 7 octobre 2021). Il ne couvre que les EDS fondés sur une mission d'intérêt public (article 6.1.e du RGPD). Un entrepôt conforme se met en œuvre sur déclaration de conformité ; un entrepôt qui s'en écarte demande une autorisation. Le référentiel couvre la constitution de l'entrepôt, pas sa réutilisation : chaque recherche, étude ou évaluation sur ses données passe par une méthodologie de référence (souvent la MR-004 pour les recherches n'impliquant pas la personne humaine) ou par une autorisation.

Accès au SNDS. La documentation du SNDS décrit les voies d'accès. Les organismes chargés d'une mission de service public listés par décret disposent d'un accès permanent. Pour les autres, la procédure standard suit quatre étapes : dossier déposé auprès de la PDS, qui en vérifie la complétude ; avis du CESREES sur la méthodologie et l'intérêt public (un mois) ; autorisation de la CNIL (deux mois, renouvelable une fois) ; mise à disposition dans un espace projet (environ deux mois). Les industriels de santé et les assureurs ont un accès encadré, avec des finalités interdites.

Méthodologies de référence SNDS. Pour les cas les plus courants, la CNIL a homologué des MR qui évitent l'autorisation individuelle : la MR-005 pour les traitements d'intérêt public et la MR-006 pour ceux menés au titre de l'intérêt légitime, notamment par les industriels, sur les données du SNDS et des résumés de passage aux urgences. La MR-006 définit une « bulle sécurisée » : une infrastructure qui cloisonne les extractions pour empêcher leur fusion. C'est une contrainte d'architecture, pas seulement juridique.

Hébergement : HDS, SecNumCloud et la migration de la PDS

La PDS héberge ses données sur Microsoft Azure depuis 2019, un choix critiqué dès l'origine pour l'exposition au droit américain. Après un appel d'offres lancé en février 2026, l'État a retenu Scaleway en avril 2026. À la date de l'annonce, Scaleway était encore en cours de qualification SecNumCloud ; la bascule de la base principale du SNDS est attendue entre fin 2026 et début 2027. Consultez la liste de l'ANSSI pour le statut actuel.

Le contexte juridique explique ce choix. L'article 31 de la loi SREN et le décret n° 2026-272 du 14 avril 2026 exigent, pour les données d'une sensibilité particulière, un cloud protégé des législations extraterritoriales, et la PDS figure parmi les entités visées. Pour un EDS d'établissement hébergé chez un tiers, la base légale reste la certification HDS, avec stockage exclusif dans l'UE/EEE depuis septembre 2026 ; voir l'hébergement HDS pour les éditeurs.

Architecture de pipeline, de la source à l'espace projet

Un découpage en zones, chacune avec ses propres droits d'accès, rend le pipeline auditable :

1. Zone d'atterrissage (identifiante). Flux HL7 v2 ADT et ORU du DPI et du SIL, extractions du PMSI fournies par le DIM, métadonnées DICOM, comptes rendus. Accès limité à l'équipe d'intégration, rétention courte, aucun accès chercheur.
2. Pseudonymisation. Les identifiants (IPP, NIR, INS) sont remplacés à l'entrée par un pseudonyme calculé avec une clé détenue par une fonction de confiance distincte de l'équipe entrepôt.
3. Zone normalisée. Modèle OMOP, vocabulaires standards, contrôles qualité.
4. Espaces projets. Une extraction par projet autorisé, limitée aux variables et à la période validées, sans possibilité de croiser deux extractions.
5. Sorties. Vérification des résultats avant export (effectifs faibles, risque de réidentification).

La pseudonymisation mérite du code plutôt qu'un schéma. Un HMAC à clé, plutôt qu'un simple hachage, empêche de retrouver un IPP en hachant toutes les valeurs possibles. Les deux clés vivent dans un HSM ou un KMS géré par la fonction de confiance, jamais dans l'entrepôt :

import datetime
import hashlib
import hmac

PSEUDO_KEY = load_key("eds-pseudo-v3")
SHIFT_KEY = load_key("eds-shift-v1")

def pseudo_id(ipp: str) -> str:
    return hmac.new(PSEUDO_KEY, ipp.encode(), hashlib.sha256).hexdigest()

def date_shift_days(ipp: str) -> int:
    # Stable per-patient shift in [-180, +180] days
    digest = hmac.new(SHIFT_KEY, ipp.encode(), hashlib.sha256).digest()
    return int.from_bytes(digest[:4], "big") % 361 - 180

row = {"ipp": "800000123", "birth_date": "1971-04-02", "loinc": "15074-8", "value": 5.4}
shift = datetime.timedelta(days=date_shift_days(row["ipp"]))
out = {
    "person_source_value": pseudo_id(row["ipp"]),
    "birth_date": (datetime.date.fromisoformat(row["birth_date"]) + shift).isoformat(),
    "measurement_source_value": row["loinc"],
    "value_as_number": row["value"],
}

Trois décisions à documenter dans le dossier CNIL. Le décalage de dates protège mais fausse les analyses saisonnières ; beaucoup d'EDS gardent les vraies dates à l'intérieur de l'environnement sécurisé. La rotation de clé change tous les pseudonymes : versionnez-la. Le texte libre contient des noms, des adresses, des numéros de téléphone ; il faut une désidentification par NLP, évaluée sur un échantillon annoté, avant toute ouverture aux chercheurs.

Normalisation OMOP : où va quoi

Le modèle commun OMOP est devenu le choix par défaut des réseaux de recherche européens. La documentation OHDSI indique que la version actuelle est la CDM v5.5 ; vérifiez la version attendue par vos partenaires avant de figer vos scripts.

Les codes français posent les vrais problèmes : extensions ATIH de la CIM-10, CCAM, codes médicaments nationaux. Selon la version des vocabulaires que vous chargez, une partie demandera un mapping local, à conserver avec la source d'origine dans les colonnes _source_value pour pouvoir le refaire. FHIR sert alors de format de transport entre le DPI et l'entrepôt, OMOP de format d'analyse ; le détail est dans le pipeline FHIR vers OMOP.

Gouvernance : ce que l'architecture doit rendre possible

• Transparence. Le référentiel CNIL impose d'informer les patients, ce qui passe en pratique par un portail listant les projets en cours.
• Opposition. Une opposition enregistrée doit être appliquée à chaque nouvelle extraction, y compris pour les projets déjà autorisés. Gérez une liste d'exclusion au niveau du pseudonyme, appliquée au moment de l'extraction ; les mécanismes sont détaillés dans les droits RGPD sur les données de santé.
• Traçabilité. Qui a accédé à quel espace projet, pour quel projet, avec quelle requête.
• Catalogue. Un dictionnaire de données à jour, avec taux de complétude par variable et par période. Il fait gagner des semaines aux chercheurs et sera exigé par l'EHDS.

Ce que l'EHDS va changer

Le règlement (UE) 2025/327 crée l'Espace européen des données de santé. Les États membres doivent désigner leurs organismes responsables de l'accès aux données de santé (HDAB) avant le 26 mars 2027, et le chapitre sur l'utilisation secondaire s'appliquera à partir de mars 2029. La PDS rappelle ce calendrier ; la stratégie nationale envisage de lui confier ce rôle, et un projet de loi était annoncé pour 2026. À la date de rédaction, je n'ai pas trouvé de désignation officielle : vérifiez avant de bâtir un argumentaire dessus.

Pour un établissement détenteur de données, l'enjeu pratique est double : décrire ses jeux de données pour un catalogue national, et pouvoir les mettre à disposition sur autorisation d'un HDAB. Un EDS déjà normalisé en OMOP, documenté et cloisonné par projet part avec une longueur d'avance. Le guide EHDS détaille le calendrier complet.

Pièges fréquents

• Traiter des données pseudonymisées comme anonymes. Elles restent des données personnelles au sens du RGPD.
• Stocker la clé de pseudonymisation dans le même projet cloud que l'entrepôt.
• Ouvrir le texte libre sans évaluation mesurée de la désidentification.
• Mapper une fois pour toutes : les vocabulaires évoluent, versionnez vos tables de correspondance.
• Copier des extractions sur des postes de chercheurs au lieu de laisser le calcul dans l'espace projet.

Si votre établissement ou votre entreprise structure un EDS ou un pipeline de recherche vers OMOP, je peux accompagner la conception dans le cadre de l'analyse de données de santé.