3 L’architecture des données patients pour l’IA est la partie d’un système clinique qui détermine si le dossier d’un patient peut être fourni de manière sûre et utile à une charge de travail d’IA — puis conservé, sous audit, pendant toute la vie de ce patient. Elle se situe entre le dossier patient informatisé (DPI, ou EHR), l’archive d’imagerie, le stockage génomique et le modèle. Lorsqu’elle fonctionne, les cliniciens bénéficient d’une aide à la décision qui reflète le patient dans sa globalité. Lorsqu’elle ne fonctionne pas, le programme d’IA s’enlise sur le consentement, la résidence des données ou la désidentification bien avant la mise en production d’un modèle. Ce guide s’adresse aux DSI, aux directeurs médicaux de l’information et aux responsables d’infrastructure qui prennent des décisions d’architecture des données patients lors du déploiement de l’IA clinique. Il aborde l’intégration au DPI, les dossiers patients longitudinaux, l’application du consentement, la désidentification conforme à HIPAA et le socle de stockage qui doit conserver les informations de santé protégées (PHI) de manière immuable et souveraine pendant des décennies. Qu’est-ce que l’architecture des données patients pour l’IA ? L’architecture des données patients pour l’IA est l’ensemble des services, des contrats et des couches de stockage qui transforment le dossier clinique d’un patient en une représentation sur laquelle un modèle d’IA peut s’entraîner, qu’il peut interroger et qu’il peut conserver — sans perdre les propriétés de confidentialité, de consentement, de résidence et d’audit qui rendent la détention de ce dossier licite. Son périmètre est plus restreint que celui d’une présentation de l’architecture d’IA dans la santé (en anglais), qui couvre toute la pile, des sources à l’inférence, et plus restreint que celui d’un système de données médicales pour l’IA (en anglais), qui décrit les composants opérationnels. L’architecture des données patients adopte le point de vue du dossier patient : comment le dossier longitudinal est assemblé, comment le consentement l’accompagne, comment les identifiants sont masqués ou rétablis, et où le dossier réside physiquement tout au long de sa période de conservation de plusieurs décennies. Trois propriétés définissent une architecture de données patients opérationnelle : Le dossier est longitudinal, et non lié à une session. Chaque patient dispose d’un dossier unique qui couvre les rencontres, les modalités et le temps, avec une identité stable dans tous les systèmes sources. Le consentement et la classification accompagnent les données. Chaque dossier, chaque dérivé et chaque artefact de modèle porte le périmètre de consentement et la classification des données qui encadrent son utilisation. L’état d’identification est explicite à chaque lecture. Le fait qu’une charge de travail lise des PHI identifiées, un dossier pseudonymisé ou un jeu de données désidentifié est une propriété de la requête, et non une convention implicite. Pourquoi les données patients sont la partie difficile de l’IA clinique La plupart des projets d’IA clinique découvrent, vers le deuxième sprint, que le modèle est la partie facile. Ce sont les données patients qui consomment le calendrier. Quatre raisons reviennent dans les systèmes hospitaliers, les réseaux d’assureurs et de prestataires de soins et les environnements de recherche pharmaceutique. L’identité du patient est fragmentée entre les systèmes sources. Un même patient peut exister sous un identifiant différent dans le DPI, le PACS de radiologie, le système de laboratoire, le séquenceur génomique et la plateforme d’objets connectés de santé. Relier ces identités relève de la gestion des données de référence, un problème dont hérite la charge de travail d’IA et qu’elle ne peut pas résoudre au moment de l’entraînement. C’est la vue longitudinale qui donne sa valeur clinique à l’IA. Un modèle qui ne voit qu’une seule rencontre — l’examen d’imagerie, le bilan biologique, le compte rendu de sortie — passe à côté de la trajectoire réelle du patient. Une IA clinique utile a presque toujours besoin du dossier longitudinal : antécédents, traitements antérieurs, imagerie antérieure, résultats biologiques antérieurs, évolutions passées. Assembler cette vue est un problème d’architecture. Le consentement est dynamique, granulaire et révocable. Un patient peut consentir à l’utilisation de son dossier désidentifié pour la recherche, mais pas à l’entraînement commercial de modèles d’IA. Il peut retirer son consentement. Il peut consentir à une étude précise, mais pas au programme de recherche général de l’établissement. L’architecture doit faire respecter ces choix, dossier par dossier, à chaque lecture des données. Les durées de conservation se comptent en décennies. Les PHI soumises à HIPAA sont assorties d’un minimum réglementaire de six ans, mais la pratique clinique conserve souvent les dossiers pendant toute la vie du patient, plus une durée légale supplémentaire. Les données génomiques et les dossiers pédiatriques peuvent être soumis à des obligations encore plus longues. Le socle qui conserve le dossier patient survit à la plupart des systèmes qui y ont écrit. Les couches clés d’une architecture des données patients pour l’IA L’architecture ci-dessous adopte le point de vue du dossier patient. D’autres guides traitent des étapes du pipeline de données cliniques et des composants plus larges du système ; ici, l’attention porte sur ce qu’il advient précisément du dossier du patient. 1. Intégration au DPI et rattachement aux sources Le point de départ est un accès structuré au dossier patient informatisé. Dans les déploiements actuels, le contrat repose sur FHIR — ressources patient, rencontre, pathologie, médicament et observation — généralement exposées par Epic, Cerner/Oracle Health, Meditech ou une passerelle FHIR neutre placée devant plusieurs systèmes. L’imagerie est rattachée via DICOMweb à un PACS ou à une archive neutre. Les données de laboratoire arrivent par des flux HL7 v2 normalisés en LOINC. Les données génomiques arrivent sous forme d’objets issus des pipelines de séquençage. Deux décisions de conception comptent à ce niveau. Premièrement, les extractions brutes de chaque source doivent être déposées sous forme d’objets immuables dans le socle de stockage avant toute transformation, afin que le dossier de référence soit auditable indépendamment des pipelines en aval. Deuxièmement, le rapprochement des identités — la liaison des identifiants patients entre les sources — doit être un service fourni par l’architecture, et non un problème que chaque consommateur en aval redécouvre. 2. Index patient principal et assemblage du dossier longitudinal Derrière l’intégration au DPI se trouve l’index patient principal (master patient index), le service qui transforme plusieurs identifiants sources en une identité patient unique et stable. Le dossier longitudinal en est la vue assemblée : chaque rencontre, observation, image et résultat biologique associé à cette identité patient, ordonné dans le temps, normalisé selon une terminologie commune (SNOMED, CIM-10, LOINC, RxNorm) et stocké sous forme d’ensemble d’objets versionnés. Pour les charges de travail d’IA, le dossier longitudinal est l’unité de l’ingénierie des caractéristiques. Un modèle de prédiction clinique est entraîné sur des cohortes de dossiers longitudinaux ; un assistant clinique fondé sur la génération augmentée par récupération ancre ses réponses dans le dossier longitudinal pertinent au moment de la requête. L’architecture doit rendre ce dossier reproductible, stable dans ses versions et traçable jusqu’à ses dossiers sources. 3. Consentement et classification Le consentement est une propriété de chaque dossier de la vue longitudinale. L’architecture doit capturer le périmètre du consentement (soins, recherche, amélioration de la qualité, entraînement commercial de modèles d’IA, identifiants d’études spécifiques), sa validité dans le temps et le droit du patient à le révoquer. La classification — PHI identifiées, jeu de données limité, données pseudonymisées, données désidentifiées selon la méthode Safe Harbor ou l’Expert Determination — est une propriété parallèle qui détermine quelles charges de travail peuvent lire le dossier. La décision d’architecture consiste ici à déterminer si le consentement et la classification sont des services annexes ou des propriétés du socle de stockage. Les services annexes dérivent, et un service de consentement qui a dérivé devient une non-conformité lors d’un audit. Une classification et une application des politiques résidant dans le stockage survivent aux changements de plateforme. La conception qui tient à grande échelle intègre les métadonnées de classification dans l’objet lui-même et les applique au niveau de la couche d’accès. 4. Désidentification, pseudonymisation et coffre-fort de PHI Les PHI identifiées constituent la catégorie de données patients la plus sensible aux yeux des régulateurs. La couche de désidentification est le service qui transforme les dossiers identifiés en représentations plus sûres pour l’IA — désidentification Safe Harbor (suppression des 18 identifiants HIPAA), Expert Determination (risque de réidentification faible démontré statistiquement) ou pseudonymisation (identifiants remplacés par des jetons stables conservés dans un coffre-fort). Une architecture de désidentification opérationnelle distingue explicitement trois états. Les PHI identifiées sont soumises aux contrôles d’accès les plus stricts et ne sont lues que par les charges de travail qui ont légitimement besoin de l’identification — soins, déclaration d’événements indésirables, contact pour le suivi. Les dossiers pseudonymisés portent des jetons stables qui permettent un chaînage longitudinal sans exposer l’identité ; ils servent à la plupart des workflows de recherche et de qualité. Les jeux de données désidentifiés sont mis à disposition pour un entraînement plus large de modèles d’IA selon une méthodologie documentée et conservés avec le lignage de leur transformation. La documentation fait partie de l’architecture. Chaque action de désidentification doit produire un enregistrement d’audit qui précise la méthode, les paramètres, l’opérateur (humain ou identité de charge de travail) et l’horodatage. C’est cet enregistrement que demandera dans deux ans un audit de l’Office for Civil Rights du HHS. Consultez le stockage conforme HIPAA (en anglais) pour les exigences au niveau du stockage qui rendent cela auditable en pratique. 5. Ingénierie des caractéristiques et accès côté modèle La couche d’accès côté modèle est celle où le dossier patient devient données d’entraînement, embeddings ou contexte pour la génération augmentée par récupération. Les pipelines d’ingénierie des caractéristiques lisent les dossiers longitudinaux normalisés et produisent des caractéristiques tabulaires, des embeddings de texte, des tenseurs d’images ou des représentations en graphe. Les workflows RAG indexent des segments de dossiers désidentifiés dans des bases vectorielles. Les points de terminaison d’inférence récupèrent le contexte du patient pertinent au moment de la requête, avec un accès lié à l’identité du clinicien demandeur et au périmètre de consentement du patient. La règle d’architecture est que chaque lecture à ce niveau est liée à une identité et tient compte de la classification. Un job d’entraînement lit des dossiers désidentifiés dans les périmètres de consentement pour lesquels il est autorisé. Un point de terminaison d’inférence au service d’un clinicien ne lit des PHI identifiées que pour les patients dont ce clinicien a la charge. La couche d’accès est l’endroit où les promesses du reste de l’architecture deviennent réellement applicables. 6. Registre des artefacts de modèles En vertu de l’AI Act européen et du 21 CFR Part 11, les artefacts de modèles dérivés des données patients — checkpoints, embeddings, jeux d’évaluation, prompts — font eux-mêmes partie du dossier réglementé. Ils doivent être conservés avec les mêmes propriétés d’immuabilité, de lignage et d’audit que les dossiers sources sur lesquels ils ont été entraînés. Le registre des artefacts est la couche qui s’en charge, et dans les architectures bien conçues, il repose sur le même socle de stockage que le dossier patient, et non dans une base de données distincte qu’il faudra rapprocher plus tard. 7. Conservation à long terme et contrôle souverain La dernière couche est le niveau de conservation pluridécennale. Les dossiers patients, les examens d’imagerie, les séquences génomiques, les pistes d’audit et les artefacts de modèles sont conservés pendant toute la vie du patient, plus les durées légales supplémentaires. Ils doivent être immuables, restaurables, soumis à des contraintes de résidence et consultables à travers les générations de supports. La couche de conservation est rarement visible pour la charge de travail d’IA — mais c’est là que finissent par lire chaque audit et chaque demande de révocation du consentement. Consultez la politique de conservation des données : définition, exemples et bonnes pratiques (en anglais) et la longévité est-elle importante pour les données de santé ? (en anglais) pour les modèles de conception qui résistent au temps. Comment les couches s’articulent Lu de haut en bas, le contrat est le suivant. Le DPI, le PACS, le laboratoire et les sources génomiques écrivent des extractions brutes sous forme d’objets immuables. L’index patient principal relie les identifiants entre les sources. La normalisation assemble le dossier longitudinal, stocké sous forme d’ensemble d’objets versionnés. Les métadonnées de consentement et de classification sont apposées sur chaque dossier. La couche de désidentification produit explicitement les états identifié, pseudonymisé et désidentifié, chacun avec son propre périmètre d’accès. L’ingénierie des caractéristiques, l’entraînement et l’inférence lisent via un accès lié à l’identité et tenant compte de la classification. Les artefacts de modèles reviennent dans le socle de stockage selon les mêmes règles que la source. Le niveau de conservation porte l’ensemble pendant des décennies sous contraintes de résidence et d’immuabilité. Lorsque ce contrat est respecté, un établissement peut ajouter une nouvelle charge de travail d’IA clinique — un outil de prédiction du sepsis, un assistant de triage en radiologie, une interface de dialogue clinique — sans reconstruire la couche des données patients. Lorsqu’il est rompu, chaque nouvelle charge de travail négocie sa propre version du consentement, de la désidentification et de l’audit, et l’architecture se fragmente en silos par application. Comment Scality ADI s’applique à l’architecture des données patients pour l’IA Scality ADI (Autonomous Data Infrastructure) est une infrastructure de données pour l’IA d’entreprise, la cyber-résilience et le contrôle souverain, qui aligne de manière autonome et durable les bons supports de stockage, de plusieurs pétaoctets à l’échelle de l’exaoctet. Pour une architecture des données patients pour l’IA dans un système clinique, c’est le socle sur lequel repose l’architecture. Concrètement, Scality ADI s’applique à l’architecture des données patients de la manière suivante : Une plateforme sur quatre niveaux. Flash GPU-direct avec S3 sur RDMA pour l’entraînement actif et le cache KV d’inférence, QLC et NL-SSD chauds pour les dossiers longitudinaux actifs et les embeddings, HDD tièdes pour les cohortes organisées et l’imagerie récente, et archivage froid sur bande ou à proximité du cloud pour la conservation pluridécennale des PHI. Le dossier patient traverse ces niveaux sans changer d’identité, de classification ni d’historique d’audit. Cyber-résilience CORE5 pour les PHI. Immuabilité, durabilité par codage à effacement, protection des métadonnées, protection multisite et application des politiques sont des propriétés de la plateforme. C’est ce qui permet aux preuves de conformité HIPAA, AI Act européen et 21 CFR Part 11 de naître au niveau du stockage plutôt que d’être reconstituées au moment de l’audit. Un contrôle souverain par conception. Scality ADI fonctionne entièrement sur site ou dans un cloud privé contrôlé par l’établissement. Les données patients restent là où les exigences de résidence l’imposent — à l’intérieur du réseau hospitalier, du pays, du périmètre du BAA — sans dépendre de l’accord de traitement des données d’un hyperscaler. Des opérations autonomes encadrées par des politiques. Les agents Guardian fournissent des analyses et des recommandations pour la migration entre niveaux, l’autoréparation, l’extension et la validation, dans le cadre des politiques définies par le client. Les humains approuvent les changements importants. La piste d’audit de chaque action opérationnelle est conservée avec les données patients qu’elle a concernées. Nativement S3 sur tout le cycle de vie. Le même protocole sert un entraînement qui lit des dossiers longitudinaux désidentifiés, un point de terminaison d’inférence qui récupère le contexte d’un patient, un job de sauvegarde qui écrit dans une archive immuable et un niveau de conservation des PHI de 25 ans sur bande. Scality ADI n’est pas un stockage objet plus rapide. C’est un nouveau modèle opérationnel pour l’infrastructure de données d’entreprise à l’ère de l’IA — et pour un système clinique, c’est la couche qui permet aux PHI identifiées, aux dossiers de recherche pseudonymisés, aux jeux d’entraînement désidentifiés et aux archives de conservation pluridécennale de partager un seul ensemble de contrôles plutôt que cinq ensembles déconnectés. Pour en savoir plus sur les modèles plus larges sur lesquels cela repose, consultez le stockage hiérarchisé pour l’IA (en anglais) et les solutions de souveraineté des données (en anglais). Questions fréquentes Qu’est-ce que l’architecture des données patients pour l’IA, en une phrase ? C’est la conception centrée sur le dossier patient — intégration au DPI, dossiers longitudinaux, consentement, classification, désidentification, accès côté modèle et conservation pluridécennale — qui transforme un dossier clinique en un élément qu’une charge de travail d’IA peut exploiter sans compromettre la confidentialité, l’audit ou la résidence des données. En quoi diffère-t-elle d’un pipeline de données cliniques ? La vue pipeline décrit les étapes que traversent les données — ingestion, normalisation, entraînement, inférence, conservation. L’architecture des données patients décrit ce qu’il advient du dossier du patient lui-même — rapprochement des identités, assemblage longitudinal, consentement, désidentification et conservation. Les deux vues sont nécessaires ; elles répondent à des questions différentes. Quelle est la place de la désidentification HIPAA ? La désidentification est une transformation explicite de l’architecture, et non une propriété de la couche de stockage. Les PHI identifiées, les dossiers pseudonymisés et les jeux de données désidentifiés sont trois états distincts ; chacun relève de son propre périmètre d’accès, et le passage d’un état à l’autre est un événement documenté et auditable. Le stockage conserve les trois états et applique les périmètres d’accès au moment de la lecture. Le consentement doit-il vraiment accompagner le dossier ? Oui. Un service de consentement distinct du dossier finit par dériver, et cette dérive devient une non-conformité lors d’un audit. Intégrer les métadonnées de consentement et de classification dans l’objet lui-même — et les appliquer au niveau de la couche d’accès — est la conception qui résiste aux contrôles de l’Office for Civil Rights du HHS et aux audits de l’AI Act européen. Quelle est la place de Scality ADI ? Scality ADI est le socle de stockage sur lequel repose l’architecture des données patients — une plateforme unique sur quatre niveaux de supports, avec immuabilité, lignage, résidence et opérations autonomes intégrés. Les extractions brutes du DPI, le stockage des dossiers longitudinaux, les corpus d’entraînement désidentifiés, les artefacts de modèles et l’archive pluridécennale des PHI résident tous sur le même socle, selon un modèle opérationnel unique. Conclusion L’architecture des données patients pour l’IA dans les systèmes cliniques ne se définit ni par le modèle qui s’y trouve ni par la base de données qui héberge le DPI. Elle se définit par ce qu’il advient du dossier du patient au fil des décennies — comment l’identité est rapprochée, comment le consentement l’accompagne, comment l’état d’identification est appliqué et quel socle conserve le dossier à travers les générations de supports et les cycles d’audit. Les établissements qui réussissent conçoivent d’abord la couche de consentement, de classification et de stockage, puis laissent chaque nouvelle charge de travail d’IA clinique s’intégrer à ce contrat. Le patient survit à chacun des systèmes de l’architecture. La couche de stockage survit à la plupart d’entre eux. C’est ce choix de conception qu’il faut réussir avant la mise en production du premier modèle. Pour aller plus loin : Présentation de l’architecture d’IA dans la santé pour les DSI (en anglais) Les systèmes de données médicales pour l’IA : conception et composants clés (en anglais) Les pipelines de données cliniques pour l’IA : guide d’architecture pratique Le stockage conforme HIPAA pour les données de santé (en anglais) La politique de conservation des données : définition, exemples et bonnes pratiques (en anglais) Le stockage hiérarchisé pour l’IA : performances évolutives et maîtrise des coûts (en anglais) Les solutions de souveraineté des données (en anglais) Qu’est-ce que le stockage immuable et comment fonctionne-t-il ? (en anglais) La longévité est-elle importante pour les données de santé ? (en anglais)
