gP2S est une application web pour le suivi des expériences cryoEM. Ses principales caractéristiques sont décrites, tout comme les étapes requises pour installer et configurer l’application. Une fois configurée, l’application permet d’enregistrer avec précision les métadonnées associées aux expériences de coloration négative et de cryoEM.
La microscopie électronique cryogénique (cryoEM) est devenue une partie intégrante de nombreux projets de découverte de médicaments parce que la cristallographie de la cible protéique n’est pas toujours réalisable et que la cryoEM fournit un moyen alternatif de soutenir la conception de ligands basée sur la structure. Lorsqu’il s’agit d’un grand nombre de projets distincts et, dans le cadre de chaque projet, d’un nombre potentiellement élevé de costructures ligand-protéines, la tenue de dossiers précis devient rapidement difficile. De nombreux paramètres expérimentaux sont réglés pour chaque cible, y compris aux stades de la préparation de l’échantillon, de la préparation de la grille et de la microscopie. Par conséquent, la tenue de dossiers précis peut être d’une importance cruciale pour permettre une reproductibilité à long terme et pour faciliter un travail d’équipe efficace, en particulier lorsque les étapes du flux de travail cryoEM sont effectuées par différents opérateurs. Pour aider à relever ce défi, nous avons développé un système de gestion de l’information basé sur le Web pour cryoEM, appelé gP2S.
L’application effectue le suivi de chaque expérience, de l’exemple au modèle atomique final, dans le contexte de projets, dont une liste est conservée dans l’application ou en externe dans un système distinct. Les vocabulaires contrôlés définis par l’utilisateur de consommables, d’équipements, de protocoles et de logiciels aident à décrire chaque étape du flux de travail cryoEM de manière structurée. gP2S est largement configurable et, selon les besoins de l’équipe, peut exister en tant que produit autonome ou faire partie d’un écosystème plus large d’applications scientifiques, intégrant via des API REST avec des outils de gestion de projet, des applications de suivi de la production de protéines ou de ligands de petites molécules, ou des applications automatisant la collecte et le stockage de données. Les utilisateurs peuvent enregistrer les détails de chaque grille et session de microscopie, y compris les métadonnées expérimentales clés et les valeurs des paramètres, et la lignée de chaque artefact expérimental (échantillon, grille, session de microscopie, carte, etc.) est enregistrée. gP2S sert d’organisateur de flux de travail expérimental cryoEM qui permet la tenue d’enregistrements précis pour les équipes, et est disponible sous une licence open source.
Gestion de l’information dans les installations cryoEM
À partir de 2014 environ, le nombre d’installations de microscopie électronique cryogénique (cryoEM)1 a augmenté de manière explosive, avec au moins 300 systèmes haut de gamme installés dans le mondeentier 2,y compris dans un certain nombre de sociétés pharmaceutiques, reflétant un rôle croissant pour cryoEM dans la découverte de médicaments3. Les missions de ces installations et leurs exigences en matière de suivi et de gestion des données diffèrent4. Certains, par exemple les centres cryoEM nationaux, sont chargés de recevoir des grilles EM, de collecter des ensembles de données et de renvoyer des données aux utilisateurs pour la détermination de la structure, peut-être après un traitement automatisé des images. Dans de telles installations, le suivi de la provenance de la grille, de son association avec une proposition ou une subvention de l’utilisateur et de la lignée d’une grille à l’autre est crucial, mais d’autres facteurs, tels que la méthode de purification de l’échantillon de protéines ou le processus éventuel de détermination de la structure, sont moins, voire pas du tout, pertinents. Dans d’autres installations, telles que les installations universitaires locales, chaque utilisateur final est responsable de la préparation de ses propres échantillons et grilles, de la réalisation de la microscopie, de la gestion des données brutes et de leur traitement et de la publication des résultats. Il n’y a pas de besoin rigoureux de suivi des métadonnées de la part d’une telle installation, car ce rôle est rempli par l’utilisateur final ou son chercheur principal.
Dans notre installation cryoEM, la manipulation et l’optimisation des échantillons, des grilles, des protocoles de collecte et de traitement des données et des résultats (cartes, modèles) sont centralisées dans de nombreux projets sur un petit groupe de praticiens. Cela présente des défis dans la gestion expérimentale des (méta)données. La lignée expérimentale des structures, du modèle atomique jusqu’à l’identité exacte des protéines et des ligands, en passant par les paramètres de préparation de la grille et les protocoles de collecte de données, doit être capturée et préservée avec précision. Ces métadonnées doivent être mises à la disposition d’un certain nombre d’opérateurs humains. Par exemple, une personne effectuant le traitement d’images peut avoir besoin de savoir quelle construction d’une protéine a été utilisée et quels étaient les paramètres d’imagerie, même si elle n’a ni purifié la protéine ni recueilli les données cryoEM elle-même; les systèmes informatiques tels que les démons de gestion automatisée des données doivent identifier le projet pour lequel un microscope collecte actuellement des données afin d’attribuer correctement et systématiquement des noms de répertoires.
Plusieurs systèmes de gestion de l’information sont disponibles pour soutenir les installations cryoEM. Peut-être le plus complet d’entre eux est EMEN25, qui combine les caractéristiques d’un cahier de laboratoire électronique, un système de gestion de l’information, et certains éléments d’un outil de gestion des processus d’affaires. Utilisé dans de nombreux synchrotrons, ISPyB6,construit à l’origine pour prendre en charge les lignes de faisceaux de rayons X pour la cristallographie, prend désormais également en charge la collecte de données cryoEM. Scipion7 est un wrapper riche et puissant autour des packages de traitement d’images, qui permet aux utilisateurs d’enregistrer des flux de travail de traitement d’images et de les partager, par exemple via le référentiel public EMPIAR8,9, et est également intégré à ISPyB pour permettre le traitement des données cryoEM à la volée.
Nous décrivons ici gP2S (pour Genentech Protein to Structure), un système de gestion de l’information cryoEM moderne et léger conçu pour prendre en charge le flux de travail depuis les protéines purifiées et les ligands à petites molécules jusqu’au modèle atomique final.
Vue d’ensemble de gP2S
gP2S est un système de gestion de l’information cryoEM basé sur le Web et convivial qui facilite la tenue de dossiers précis pour les laboratoires cryoEM et les installations multi-utilisateurs et multi-projets. Les entités suivantes, leurs relations et les métadonnées associées sont suivies : projets, équipements, consommables, protocoles, échantillons, grilles, sessions de microscopie, sessions de traitement d’images, cartes et modèles atomiques. Les utilisateurs peuvent également ajouter des commentaires en texte libre, y compris éventuellement des pièces jointes, ce qui permet une annotation riche de toute entité enregistrée dans gP2S. Le front-end a été conçu pour faciliter l’utilisation avec des appareils à écran tactile et testé de manière approfondie sur les iPad Pros de 12,9 pouces, ce qui permet d’utiliser le gP2S sur le banc du laboratoire lors de la préparation d’échantillons et de grilles(Figure 1),ainsi qu’à l’ordinateur lors de l’utilisation du microscope, du traitement d’images ou du dépôt de modèles. Chaque page du front-end vise à réduire la saisie manuelle des données en pré-définissant les paramètres sur des valeurs par défaut raisonnables lorsque cela est possible.
Le backend de gP2S dispose d’un certain nombre de points de terminaison REST API (REpresentational State Transfer Application Programming Interface), ce qui permet d’intégrer gP2S dans des workflows et des scripts existants. Le modèle de données a été conçu pour permettre la capture précise des flux de travail négatifs de coloration et de cryoEM, y compris la ramification, par exemple avec un échantillon utilisé sur plusieurs grilles, la fusion des données de plusieurs sessions de microscopie en une seule session de traitement des données ou une session de traitement des données donnant plusieurs cartes.
Architecture du système
gP2S est une application classique à trois niveaux (Figure 2). Dans cette architecture modulaire, le système est divisé en trois couches distinctes, chacune responsable de l’exécution de tâches distinctes, et chacune remplaçable ou modifiable indépendamment des autres. (1) La couche de présentation (ou frontend) fournit un accès utilisateur via un navigateur Web (largement testé avec Chrome et Safari), permet de créer et de modifier des éléments de flux de travail (y compris la validation des données) et affiche les données expérimentales sous forme d’entités individuelles, de listes basées sur des projets et de rapports de flux de travail complets. (2) La couche de service (ou backend) sert de couche intermédiaire entre l’interface utilisateur et le système de stockage – elle contient la logique métier de base, expose l’API de service utilisée par le frontend, s’intègre au stockage de données et au système LDAP (Lightweight Directory Access Protocol) pour l’authentification des utilisateurs, et fournit une base pour une intégration supplémentaire avec des systèmes externes. (3) La couche de persistance (accès aux données) est responsable du stockage des données expérimentales, des commentaires des utilisateurs et des pièces jointes.
Technologies et cadres clés
Afin de faciliter le développement, la construction et la maintenance de l’application gP2S, plusieurs technologies et cadres ont été utilisés dans le projet. Les plus importants sont: Vue.js 2.4.210 pour le frontend et SpringBoot 1.311 avec le serveur Tomcat 8 intégré pour le backend. L’application utilise les bases de données MySQL 5.7 et MongoDB 4.0.6 pour le stockage et LDAP12 pour l’authentification. Par défaut, tous ces composants sont livrés et déployés en tant qu’application.
Au total, l’application utilise des centaines de bibliothèques différentes directement ou indirectement. Les plus importants sont énumérés dans le tableau 1.
modèle de données
Trois types d’entités peuvent être distingués dans le modèle de données gP2S(figure 3): les entités de flux de travail liées aux données recueillies au cours d’expériences (p. ex. échantillons ou séances de microscopie); l’équipement et les entités de protocole qui décrivent des données communes à tous les projets (p. ex. microscopes ou protocoles de vitrification); d’autres entités qui jouent un rôle de soutien ou un rôle technique dans le système (p. ex., commentaires ou valeurs par défaut).
La racine de l’arborescence de données de flux de travail est l’entité Project. Chaque projet se compose d’un certain nombre de protéines et / ou de ligands qui sont des blocs de construction pour la création d’entités d’échantillon. Chaque échantillon peut être utilisé pour créer plusieurs grilles qui à leur tour sont utilisées dans les sessions de microscopie (une grille par session de microscopie). Ces derniers sont affectés à des sessions de traitement qui peuvent générer un ou plusieurs mappages. La dernière entité de l’arborescence est le modèle atomique, créé à l’aide d’une ou de plusieurs cartes. En conséquence, chaque entité liée au flux de travail, de la protéine au modèle, est toujours liée à un projet particulier via ses ancêtres. Une telle conception crée des agrégats de données faciles à traiter par le module frontal ou par des systèmes externes à l’aide de l’API.
En plus des données de flux de travail, il existe des entités qui décrivent l’équipement utilisé dans des expériences ou des protocoles qui ont été suivis lors de la préparation des grilles. La définition de ces entités est une condition préalable à la création d’entités de flux de travail expérimentales telles que les grilles, la microscopie et les sessions de traitement.
Le dernier type d’entité de données, collectivement nommé « Autre », est utilisé à des fins techniques (p. ex., pièces jointes ou valeurs par défaut). Cette catégorie inclut les entités de commentaires qui peuvent être liées à n’importe quelle entité de flux de travail ou d’équipement/protocole.
Disponibilité des logiciels
La version open-source de gP2S est disponible sous une licence Apache Version 2.026, à partir de https://github.com/arohou/gP2S. Une image Docker pour exécuter gP2S est disponible à partir de https://hub.docker.com/r/arohou/gp2s. Une branche à source fermée de gP2S est en cours de développement chez Roche &Genentech.
Exécution de l’application gP2S
Il existe deux façons d’exécuter gP2S : en tant que conteneur docker ou en tant qu’application Java autonome. Le choix optimal dépendra de l’environnement de déploiement cible. Par exemple, si la possibilité de personnaliser ou d’améliorer le code pour répondre aux besoins spécifiques des utilisateurs est souhaitée, l’application entière doit d’abord être régénérée. Dans ce cas, l’exécution de gP2S en tant qu’application autonome peut être recommandée.
Conteneur Docker
Le moyen le plus simple de commencer à travailler avec l’application gP2S consiste à l’exécuter en tant que service Docker. À cette fin, une image Docker dédiée a été préparée et publiée dans le référentiel Docker Hub (« https://hub.docker.com/r/arohou/gp2s »). L’exécution de l’image gP2S dépend de l’accès aux bases de données MySQL et MongoDB, ainsi qu’à un serveur LDAP. Pour les environnements hors production, il est recommandé d’exécuter toutes ces dépendances en tant qu’applications Docker multi-conteneurs avec l’application gP2S. Pour rendre cela transparent, un fichier docker-compose (https://github.com/arohou/gP2S/blob/master/docker-compose.yml) qui inclut toutes les configurations nécessaires de l’environnement final a été préparé et fourni dans le référentiel GitHub gP2S (https://github.com/arohou/gP2S). Les images docker suivantes sont des dépendances: mysql27, mongodb28, apacheds29.
Dans la configuration par défaut, toutes les données stockées, les entités et les pièces jointes seront supprimées lors de la suppression des conteneurs docker. Afin de conserver les données, soit les volumes docker doivent être utilisés, soit l’application gP2S doit être connectée à des instances de base de données dédiées (MySQL et MongoDB). Le conteneur de serveur LDAP ApacheDS est livré avec un utilisateur administrateur préconfiguré (mot de passe : secret). Ces informations d’identification doivent être utilisées pour se connecter à l’application gP2S lorsqu’elle est exécutée en tant que service Docker.These credentials should be used to log in to the gP2S application when it is run as a Docker service. Pour les environnements de production, le même fichier docker-compose peut être utilisé pour déployer gP2S (et d’autres conteneurs si nécessaire) en tant que services sur une plateforme d’orchestration de conteneurs Docker Swarm.
Le processus complet d’exécution de gP2S en tant que conteneur Docker, y compris tous les détails concernant la configuration appropriée, est décrit dans le référentiel GitHub gP2S et couvre les rubriques suivantes :The full process of running gP2S as a Docker container, including all details regarding proper configuration is described in the gP2S GitHub repository and covers the following topics:
• Exécution de l’application dockerisée gP2S avec toutes les dépendances.
• Accès à l’application gP2S, à la base de données et au PROTOCOLE LDAP.
• Mise à jour du service gP2S avec une nouvelle version.
• Suppression de l’application gP2S.
• Configuration de la persistance des données.
• Connexion de l’application gP2S dockerisée à des bases de données dédiées ou à un serveur LDAP.
• Détails de configuration
Application Java autonome
Une autre option pour exécuter l’application gP2S consiste à créer un package Java autonome. Cette approche doit être adoptée si l’exécution de conteneurs Docker n’est pas possible. La création de l’application gP2S nécessite l’installation d’un Kit de développement Java version 8 ou supérieure. L’ensemble du processus de génération est géré par l’outil Maven, qui est fourni dans la base de code du référentiel GitHub.The whole build process is managed by the Maven tool, which is provided in the codebase in GitHub repository. La configuration de build est préparée pour générer d’abord la partie frontale, puis la copier vers des sources principales, puis la générer en tant qu’application finale. De cette façon, il n’est pas nécessaire d’installer d’autres outils ou bibliothèques afin de préparer un package gP2S pleinement fonctionnel. Par défaut, le résultat de la génération est un package JAR (stocké localement) et une image Docker (envoyée au référentiel configuré dans le fichier maven pom.xml). Il est important de se rappeler que les informations requises pour se connecter à des systèmes externes (bases de données et serveur LDAP) doivent être fournies dans un fichier de configuration approprié avant que le package ne soit généré.
Une fois le package JAR gP2S créé, il contient toutes les dépendances et informations de configuration nécessaires à l’exécution de l’application, y compris le serveur d’applications Tomcat qui héberge le système. Si le package a été généré avec plusieurs fichiers de configuration, il peut être exécuté dans différents modes sans reconstruction.
Le référentiel GitHub gP2S inclut une description complète du processus de création et d’exécution de gP2S en tant qu’application autonome et couvre les rubriques suivantes :
• Construction de gP2S à l’aide de l’outil Maven
• Création et exécution avec des bases de données intégrées
• Création et exécution avec des dépendances déployées en tant que conteneurs docker
• Création et exécution avec des bases de données dédiées
• Configuration de l’authentification
Lorsqu’il est utilisé correctement et de manière cohérente, gP2S aide à assurer la tenue de dossiers appropriés des métadonnées de haute qualité en appliquant l’enregistrement des métadonnées expérimentales critiques à l’aide de modèles de données structurées et de vocabulaires définis, mais la valeur ajoutée de cela n’est pleinement réalisée que lorsqu’un niveau élevé de conformité est atteint en laboratoire. Le protocole ci-dessus ne couvre pas comment y parvenir. Nous avons constaté qu’une technique d’application efficace consistait à faire en aire les opérateurs de microscopes pour refuser de recueillir des données sur des grilles non enregistrées dans le gP2S. Cela a conduit la conformité très rapidement et a jeté les bases de l’émergence, au cours des mois suivants, d’un grand nombre de détails expérimentaux détaillés et précis et de mémoire institutionnelle. Après quelques mois d’utilisation, la valeur du corpus de métadonnées stockées dans gP2S est devenue si évidente pour la plupart des utilisateurs que la conformité est restée élevée sans intervention explicite.
Pour tirer pleinement parti de cette mémoire collective, il faut que les métadonnées stockées dans gP2S soient accessibles aux systèmes externes et facilement associées aux données expérimentales (micrographies) et aux résultats (cartes et modèles). Le protocole ci-dessus ne décrit pas comment intégrer gP2S à d’autres systèmes informatiques et de traitement de données. Les plus simples sont les intégrations potentielles via l’API REST backend de gP2S, qui ne nécessitent aucune modification de gP2S. Par exemple, chaque ordinateur contrôlant nos détecteurs de collecte de données exécute un script qui interroge périodiquement le point de terminaison de gP2S « getItemByMicroscope » sous le contrôleur REST de gestion de session de microscopie, pour vérifier si une session de microscopie est en cours sur son microscope. Si tel est le cas, le script récupère à partir de gP2S le nom du répertoire de stockage de données approprié (tel que configuré dans la page Paramètres, voir ci-dessus) et crée un répertoire sur le périphérique de stockage de données local à l’aide de ce nom. Cela garantit un nom systématique des répertoires de stockage de données et réduit le risque d’erreur dû aux fautes de frappe.
Bien qu’elles aient été commentées dans la source de la version publique de gP2S, d’autres intégrations impliquant gP2S consommant des données de systèmes externes sont également possibles. Dans notre laboratoire, notre déploiement de gP2S s’intègre à (i) un système de gestion de projet, de sorte que chaque projet configuré dans gP2S peut être lié à un projet de portefeuille à l’échelle de l’entreprise, et les métadonnées du portefeuille peuvent être affichées dans gP2S; ii) un système d’enregistrement des protéines, de sorte que chaque protéine ajoutée au gP2S soit liée, au moyen d’un identificateur stocké localement, à un ensemble complet d’enregistrements détaillant la provenance de la protéine, y compris des détails sur la biologie moléculaire, le système d’expression et la purification pertinents; (iii) un système de gestion des composés de petites molécules, permettant à gP2S d’afficher des informations clés sur chaque ligand, telles que sa structure chimique. Les modifications de code nécessaires pour activer ces intégrations sont décrites dans la section « Intégration » du document README-BUILD.md disponible dans le référentiel gP2S (https://github.com/arohou/gP2S).
La version actuelle de gP2S présente des limites, au premier rang desquelles le modèle de données trop simpliste et le frontend pour le dépôt de structure (modèle). Cela a été intentionnellement laissé dans un état « barebones » dans la version publiée de gP2S parce qu’une fonction de dépôt et de validation de structure à part entière est actuellement en cours de développement avec la prise en charge de la cristallographie aux rayons X. Une autre décision de conception a été de ne pas implémenter de système de privilèges ou d’autorisations: tous les utilisateurs de gP2S ont un accès égal à ses fonctionnalités et données. Cela peut en faire un mauvais choix pour les installations qui desservent des groupes d’utilisateurs ayant des intérêts concurrents et des exigences de confidentialité, mais ce n’était pas une préoccupation pour notre installation.
Le développement de notre version interne de gP2S est en cours et nous espérons que la version open-source décrite ici sera utile à d’autres groupes cryoEM, et que certains pourront apporter des suggestions ou des améliorations de code à l’avenir. Les développements futurs à forte valeur ajoutée pourraient par exemple se concentrer sur les intégrations avec des équipements de laboratoire (robots de vitrification, microscopes électroniques), des logiciels (par exemple pour récolter des métadonnées de traitement d’images) et des dépôts publics externes (par exemple pour faciliter les dépôts de structures).
La collecte systématique de métadonnées de haute qualité rendue possible par l’utilisation systématique de gP2S en laboratoire et dans l’installation cryoEM peut avoir un impact significatif et positif sur la capacité de poursuivre plusieurs projets en parallèle sur une période de plusieurs années. À mesure que de plus en plus de groupes et d’installations cryoEM partagés et centralisés sont établis, nous prévoyons que le besoin de systèmes de gestion de l’information tels que gP2S continuera de croître.
The authors have nothing to disclose.
Les auteurs remercient tous les autres membres de l’équipe de développement de gP2S qui ont travaillé sur le projet depuis sa création : Rafał Udziela, Cezary Krzyżanowski, Przemysław Stankowski, Jacek Ziemski, Piotr Suchcicki, Karolina Pająk, Ewout Vanden Eyden, Damian Mierzwiński, Michał Wojtkowski, Piotr Pikusa, Anna Surdacka, Kamil Łuczak et Artur Kusak. Nous remercions également Raymond Ha et Claudio Ciferri d’avoir aidé à constituer l’équipe et à façonner le projet.