💡 Vous pouvez consulter la page ci-dessous pour avoir le détail de l'architecture de l'application :
https://www.notion.so/225403a7adf380cf92c4d40382383f1e
¶ Admin/Explore
¶ Admin
Admin est le centre de contrĂ´le de la plateforme.
Il englobe de nombreux aspects de la gestion de l'EDS :
- gérer les catalogues de données ;
- créer des datamarts ;
- contrôler l'accès ;
- gérer les Data Cleanrooms.
¶ Explore
Explore permet aux investigateurs médicaux de créer des cohortes. Les équipes médicales peuvent interroger la base de données Arkhn pour identifier les patients correspondant à un ensemble de critères (démographiques, cliniques, biologiques) et exporter la cohorte.
¶ Datalake
Le Datalake fait référence à l'ensemble des composants responsables du stockage des données au sein de la plateforme Arkhn.
Les données structurées sont stockées dans ClickHouse, une base de données orientée colonnes, tandis que les données non structurées sont stockées dans MinIO, une solution de stockage d'objets. En outre, Elasticsearch peut être utilisé pour stocker des données et fournit un moteur de recherche pour les explorer.
Le Datalake centralise des données hétérogènes provenant de diverses bases de données clients et fournit une structure unifiée, conçue pour servir de datamart destiné à la recherche scientifique des équipes médicales.
¶ Traitement des données
Le traitement des données au sein de la plateforme suit le cadre ELT (Extract, Load, Transform). Les principales étapes sont les suivantes :
- Importer des données structurées à partir de diverses bases de données de clients à l'aide du pont JDBC de ClickHouse ;
- Stocker les données structurées dans une zone "raw" du Datalake (ClickHouse) ;
- Importer des documents non structurés à partir de diverses sources telles que des bases de données, des lecteurs réseau ou des buckets S3 ;
- Stocker des données non structurées dans une zone "raw" du Datalake (MinIO) ;
- Extraire du texte Ă partir de documents ;
- Pseudonymiser les données non structurées ;
- Extraire des données structurées à partir de données non structurées grace à un agent IA local ;
- Comparer, assembler et recouper les données pour créer des tables pivots ;
- Normaliser les données dans les tables OMOP et FHIR.
Dagster orchestre quotidiennement toutes ces Ă©tapes en mode batch.
Le développement data directement sur la plateforme se fait grâce à l'instance de coder integrée à la plateforme.
¶ Data Cleanroom
Les Data Cleanrooms (aussi appelées bulles sécurisées) sont des environnements sécurisés où les utilisateurs de l'hôpital peuvent traiter et analyser des données de santé (provenant de l'EDS ou d'autres sources) en totale conformité avec les directives EDS de la CNIL. Ces exigences sont définies dans les lignes directrices suivantes :
- Un contrôle strict des exportations de données : les fichiers exportés doivent être examinés et autorisés par un responsable ;
- Contrôle strict de l'accès au réseau : aucun accès à l'internet ou à l'intranet n'est autorisé, sauf autorisation explicite ;
- Contrôle d'accès granulaire : les utilisateurs de DCR ne peuvent accéder qu'aux DCR et aux données qu'ils sont autorisés à utiliser ;
- Authentification Ă plusieurs facteurs : les utilisateurs de DCR doivent s'authentifier Ă l'aide d'un TOTP en plus de leur mot de passe ;
- Restrictions du presse-papier : la copie de la DCR vers le presse-papier local est désactivée afin d'éviter l'exfiltration de données.
Les Data managers peuvent créer et gérer des DCR via l'interface Admin d'Arkhn.
D'un point de vue technique, une DCR est une machine virtuelle alimentée par KVM et orchestrée par KubeVirt (un module complémentaire de Kubernetes pour la gestion des VM). Elle est isolée du réseau à l'aide des politiques réseau de Kubernetes. Les connexions des utilisateurs sont facilitées par Apache Guacamole, qui gère la connexion RDP à la VM et transmet le bureau à distance via son propre protocole web, ce qui permet aux utilisateurs d'accéder à leurs DCR via un navigateur web standard. L'authentification à Guacamole est sécurisée par le moteur SSO de Keycloak.
¶ Installation de Packages dans les DCR
Les utilisateurs de Data Clean Room ont souvent besoin d'installer des bibliothèques supplémentaires pour effectuer leurs tâches d'analyse de données. L'environnement DCR fournit un moyen sécurisé et contrôlé d'installer ces dépendances tout en maintenant la conformité aux exigences de sécurité.
Comment Fonctionne l'Installation de Bibliothèques
Quand un utilisateur a besoin d'installer une bibliothèque, le système suit un workflow sécurisé à travers notre système de gestion de dépôts Nexus. L'environnement DCR utilise une instance Nexus locale qui s'exécute dans le cluster Kubernetes du client, qui agit comme un proxy sécurisé vers notre infrastructure Nexus Arkhn centralisée.
Architecture Nexus
L'environnement DCR opère avec une configuration Nexus hybride :
- Nexus Local : une instance Nexus locale incluse dans chaque stack DCR client et s'exécutant dans leur cluster Kubernetes ;
- Nexus Arkhn Central : notre système de gestion de dépôts centralisé qui agit comme la source autoritaire
Comment le Proxy Fonctionne
Le Nexus local fonctionne comme un proxy qui :
- Reçoit les requêtes des utilisateurs DCR pour les packages Python/R ;
- « Proxify » vers le Nexus Arkhn Centralisé.
Fonctionnalités de Sécurité
- Isolation Réseau : tous les téléchargements de packages passent par le proxy Nexus sécurisé ;
- Contrôle de Liste Blanche : seuls les packages pré-approuvés peuvent être installés.
Cette approche assure que les utilisateurs ont accès aux outils dont ils ont besoin tout en maintenant les exigences de sécurité strictes de l'environnement Data Cleanroom, car toute la gestion de packages se passe sur notre infrastructure Nexus sécurisée et contrôlée.
¶ Observabilité/surveillance
La surveillance et l'observabilité nous permettent de suivre l'état et les performances de notre infrastructure et de nos applications.
Dans chaque environnement, nous collectons des métriques et des journaux pour une surveillance locale. De plus, nous centralisons les métriques au sein de notre infrastructure pour l'analyse et l'alerte à distance.
Le système d'observabilité de la plateforme Arkhn comprend :
- Prometheus : collecte et stocke les métriques ;
- Grafana : visualise les métriques à travers des tableaux de bord ;
- cAdvisor : fournit des métriques sur les nœuds ;
- Mimir : centralise les métriques des environnements distants ;
- Elasticsearch : stocke les journaux et gère les requêtes de recherche ;
- Kibana : permet aux utilisateurs d'interroger et de visualiser les données dans Elasticsearch ;
- Filebeat : collecte les journaux des nœuds et des pods.
¶ Gestion des secrets
Dans la plateforme Arkhn, HashiCorp Vault sécurise le stockage et le cycle de vie des secrets. Il sert de stockage de secrets pour les informations statiques d'identification et agit comme une PKI (Public Key Infrastructure) pour l'émission de certificats TLS internes. Ses contrôles d'accès très fins permettent de mettre en œuvre le principe du moindre privilège. En outre, le Vault Secret Operator distribue automatiquement et en toute sécurité les secrets aux applications au sein du cluster k3s.
¶ SSO
Le Single Sign-On (SSO) est un mécanisme d'authentification qui permet aux utilisateurs d'accéder à plusieurs applications avec un seul jeu d'identifiants. Sur la plateforme Arkhn, le SSO est géré par Keycloak. Les identités des utilisateurs dans Keycloak peuvent être fédérées avec les systèmes LDAP ou Active Directory du client.