gP2S è un’applicazione web per il monitoraggio degli esperimenti crioEM. Vengono descritte le sue caratteristiche principali, così come i passaggi necessari per installare e configurare l’applicazione. Una volta configurata, l’applicazione consente di registrare con precisione i metadati associati a macchie negative ed esperimenti crioEM.
La microscopia elettronica criogenica (crioEM) è diventata parte integrante di molti progetti di scoperta di farmaci perché la cristallografia del bersaglio proteico non è sempre raggiungibile e la crioEM fornisce un mezzo alternativo per supportare la progettazione del ligando basato sulla struttura. Quando si ha a che fare con un gran numero di progetti distinti, e all’interno di ogni progetto un numero potenzialmente elevato di co-strutture ligando-proteina, una registrazione accurata diventa rapidamente impegnativa. Molti parametri sperimentali sono sintonizzati per ogni bersaglio, anche nelle fasi di preparazione del campione, preparazione della griglia e microscopia. Pertanto, una registrazione accurata può essere di fondamentale importanza per consentire la riproducibilità a lungo termine e per facilitare un efficiente lavoro di squadra, specialmente quando le fasi del flusso di lavoro crioEM vengono eseguite da diversi operatori. Per contribuire ad affrontare questa sfida, abbiamo sviluppato un sistema di gestione delle informazioni basato sul web per cryoEM, chiamato gP2S.
L’applicazione tiene traccia di ogni esperimento, dal campione al modello atomico finale, nel contesto dei progetti, il cui elenco viene mantenuto nell’applicazione o esternamente in un sistema separato. I vocabolari controllati definiti dall’utente di materiali di consumo, apparecchiature, protocolli e software aiutano a descrivere ogni fase del flusso di lavoro crioEM in modo strutturato. gP2S è ampiamente configurabile e, a seconda delle esigenze del team, può esistere come prodotto autonomo o far parte di un ecosistema più ampio di applicazioni scientifiche, integrandosi tramite API REST con strumenti di gestione dei progetti, applicazioni che tracciano la produzione di proteine o di ligandi di piccole molecole o applicazioni che automatizzano la raccolta e l’archiviazione dei dati. Gli utenti possono registrare i dettagli di ogni sessione di griglia e microscopia, inclusi i metadati sperimentali chiave e i valori dei parametri, e viene registrata la discendenza di ogni artefatto sperimentale (campione, griglia, sessione di microscopia, mappa, ecc.). gP2S funge da organizzatore sperimentale del flusso di lavoro crioEM che consente una registrazione accurata per i team ed è disponibile con una licenza open source.
Gestione dell’informazione presso le strutture crioEM
A partire dal 2014 circa, il numero di impianti di microscopia elettronica criogenica (crioEM)1 è cresciuto in modo esplosivo, con almeno 300 sistemi di fascia alta installati intutto il mondo 2,anche in un certo numero di aziende farmaceutiche, riflettendo un ruolo crescente per il crioEM nella scoperta di farmaci3. Le missioni di queste strutture e i loro requisiti per il monitoraggio e la gestione dei dati differiscono4. Alcuni, ad esempio i centri crioEM nazionali, sono incaricati di ricevere griglie EM, raccogliere set di dati e restituire dati agli utenti per la determinazione della struttura, magari dopo un’elaborazione automatizzata delle immagini. In tali strutture, il monitoraggio della provenienza della griglia, la sua associazione con una proposta o una sovvenzione dell’utente e il lignaggio dalla griglia al set di dati è fondamentale, ma altri fattori, come il metodo di purificazione del campione proteico o l’eventuale processo di determinazione della struttura, sono meno o per niente rilevanti. In altre strutture, come le strutture accademiche locali, ogni utente finale è responsabile della preparazione dei propri campioni e griglie, dell’esecuzione della microscopia, della gestione dei dati grezzi e della sua elaborazione e pubblicazione dei risultati. Non vi è alcuna necessità rigorosa di tracciamento dei metadati da parte di tale funzionalità perché questo ruolo è svolto dall’utente finale o dal suo investigatore principale.
Nella nostra struttura crioEM, la gestione e l’ottimizzazione di campioni, griglie, protocolli di raccolta ed elaborazione dei dati e risultati (mappe, modelli) è centralizzata in molti progetti su un piccolo gruppo di professionisti. Ciò presenta sfide nella gestione sperimentale (meta)dei dati. La discendenza sperimentale delle strutture, dal modello atomico fino all’identità esatta di proteine e ligandi, attraverso parametri di preparazione della griglia e protocolli di raccolta dei dati, deve essere accuratamente catturata e preservata. Questi metadati devono essere messi a disposizione di diversi operatori umani. Ad esempio, una persona che elabora immagini potrebbe aver bisogno di sapere quale costrutto di una proteina è stato utilizzato e quali sono stati i parametri di imaging, anche se non ha purificato la proteina né raccolto i dati crioEM stessi; i sistemi informatici come i daemon di gestione automatizzata dei dati devono identificare il progetto per il quale un microscopio sta attualmente raccogliendo dati al fine di assegnare correttamente e sistematicamente i nomi delle directory.
Sono disponibili diversi sistemi di gestione delle informazioni per supportare le strutture crioEM. Forse il più completo tra questi è EMEN25, che combina le funzionalità di un notebook di laboratorio elettronico, un sistema di gestione delle informazioni e alcuni elementi di uno strumento di gestione dei processi aziendali. Utilizzato in molti sincrotroni, ISPyB6, originariamente costruito per supportare le linee di fascio a raggi X per la cristallografia, ora supporta anche la raccolta dei dati crioEM. Scipion7 è un wrapper ricco e potente intorno ai pacchetti di elaborazione delle immagini, che consente agli utenti di registrare i flussi di lavoro di elaborazione delle immagini e condividerli, ad esempio tramite il repository pubblico EMPIAR8,9, ed è anche integrato con ISPyB per consentire l’elaborazione dei dati cryoEM al volo.
Qui descriviamo gP2S (per Genentech Protein to Structure), un moderno e leggero sistema di gestione delle informazioni crioEM costruito per supportare il flusso di lavoro dalle proteine purificate e dal ligando di piccole molecole fino al modello atomico finale.
Panoramica di gP2S
gP2S è un sistema di gestione delle informazioni crioEM basato sul web di facile utilizzo che facilita la registrazione accurata per i laboratori crioEM e le strutture multi-utente e multi-progetto. Vengono tracciate le seguenti entità, le relative relazioni e i metadati associati: progetti, apparecchiature, materiali di consumo, protocolli, campioni, griglie, sessioni di microscopia, sessioni di elaborazione delle immagini, mappe e modelli atomici. Gli utenti possono anche aggiungere commenti a testo libero, facoltativamente includendo file allegati, consentendo una ricca annotazione di qualsiasi entità registrata in gP2S. Il front-end è stato progettato per facilitare l’uso con dispositivi touchscreen e testato ampiamente su iPad Pro da 12,9″, rendendo possibile l’utilizzo di gP2S sul banco di laboratorio durante la preparazione di campioni e griglie(Figura 1),nonché al computer quando si utilizza il microscopio, si elaborano immagini o si depositano modelli. Ogni pagina del front-end mira a ridurre l’immissione manuale dei dati pre-impostando i parametri su valori predefiniti ragionevoli quando possibile.
Il back-end di gP2S presenta una serie di endpoint REST API (REpresentational State Transfer Application Programming Interface), che consente di integrare gP2S nei flussi di lavoro e negli script esistenti. Il modello di dati è stato progettato per consentire l’acquisizione accurata di flussi di lavoro negativi di macchie e crioEM, inclusa la diramazione, ad esempio con un campione utilizzato su più griglie, i dati di diverse sessioni di microscopia che vengono uniti in una singola sessione di elaborazione dei dati o una sessione di elaborazione dati che produce diverse mappe.
Architettura di sistema
gP2S è un’applicazione classica a tre livelli (Figura 2). In questa architettura modulare, il sistema è suddiviso in tre strati separati, ognuno responsabile dell’esecuzione di compiti distinti, e ognuno sostituibile o modificabile indipendentemente dagli altri. (1) Il livello di presentazione (o frontend) fornisce l’accesso degli utenti tramite browser Web (ampiamente testato con Chrome e Safari), consente di creare e modificare elementi del flusso di lavoro (inclusa la convalida dei dati) e visualizza dati sperimentali come singole entità, elenchi basati su progetti e report completi del flusso di lavoro. (2) Il livello di servizio (o back-end) funge da livello intermedio tra l’interfaccia utente e il sistema di archiviazione: contiene la logica aziendale di base, espone l’API di servizio utilizzata dal frontend, si integra con l’archiviazione dei dati e il sistema LDAP (Lightweight Directory Access Protocol) per l’autenticazione utente e fornisce una base per un’ulteriore integrazione con i sistemi esterni. (3) Il livello di persistenza (accesso ai dati) è responsabile dell’archiviazione di dati sperimentali, commenti degli utenti e file allegati.
Tecnologie e quadri chiave
Al fine di facilitare lo sviluppo, la costruzione e la manutenzione dell’applicazione gP2S, nel progetto sono state utilizzate diverse tecnologie e framework. I più importanti sono: Vue.js 2.4.210 per frontend e SpringBoot 1.311 con server Tomcat 8 incorporato per il back-end. L’applicazione utilizza database MySQL 5.7 e MongoDB 4.0.6 per l’archiviazione e LDAP12 per l’autenticazione. Per impostazione predefinita, tutte queste parti componenti vengono spedite e distribuite come un’unica applicazione.
In totale l’applicazione utilizza centinaia di librerie diverse direttamente o indirettamente. I più importanti sono elencati nella tabella 1.
Modello di dati
Nel modello di dati gP2S possono essere distinti tre tipi di entità (Figura 3): entità del flusso di lavoro relative ai dati raccolti durante gli esperimenti (ad esempio, campioni o sessioni di microscopia); apparecchiature ed entità di protocollo che descrivono dati comuni in tutti i progetti (ad esempio, microscopi o protocolli di vetrificazione); altre entità che svolgono ruoli di supporto o tecnici nel sistema (ad esempio, commenti o valori predefiniti).
La radice della struttura dei dati del flusso di lavoro è l’entità Progetto. Ogni progetto è costituito da un certo numero di proteine e/o ligandi che sono elementi costitutivi per la creazione di entità campione. Ogni campione può essere utilizzato per creare più griglie che a loro volta vengono utilizzate nelle sessioni di microscopia (una griglia per sessione di microscopia). Questi ultimi vengono assegnati a sessioni di elaborazione che possono produrre una o più mappe. L’ultima entità nell’albero è il modello atomico, creato utilizzando una o più mappe. Di conseguenza, ogni entità legata al flusso di lavoro, da Protein a Model, è sempre legata a un particolare Progetto tramite i suoi antenati. Tale progettazione crea aggregati di dati facili da elaborare dal modulo frontend o da sistemi esterni che utilizzano l’API.
Oltre ai dati del flusso di lavoro, sono disponibili entità che descrivono le apparecchiature utilizzate negli esperimenti o nei protocolli seguiti durante la preparazione delle griglie. La definizione di queste entità è un prerequisito per la creazione di entità sperimentali del flusso di lavoro come Griglie, Microscopia ed Elaborazione di sessioni.
L’ultimo tipo di entità dati, collettivamente denominata “Altro”, viene utilizzato per scopi tecnici (ad esempio, file allegati o valori predefiniti). Questa categoria include entità di commento che possono essere collegate a qualsiasi flusso di lavoro o entità di apparecchiature/protocollo.
Disponibilità del software
La versione open source di gP2S è disponibile sotto licenza Apache versione 2.026,da https://github.com/arohou/gP2S. Un’immagine Docker per eseguire gP2S è disponibile da https://hub.docker.com/r/arohou/gp2s. Un ramo closed source di gP2S è in continuo sviluppo presso Roche & Genentech.
Esecuzione dell’applicazione gP2S
Esistono due modi per eseguire gP2S: come contenitore docker o come applicazione Java autonoma. La scelta ottimale dipenderà dall’ambiente di distribuzione di destinazione. Ad esempio, se si desidera personalizzare o migliorare il codice in base alle esigenze specifiche degli utenti, l’intera applicazione deve essere ricostruita per prima. In questo caso, potrebbe essere consigliata l’esecuzione di gP2S come applicazione autonoma.
Contenitore Docker
Il modo più semplice per iniziare a lavorare con l’applicazione gP2S è eseguito come servizio Docker. A tale scopo, un’immagine Docker dedicata è stata preparata e pubblicata nel repository Docker Hub (“https://hub.docker.com/r/arohou/gp2s”). L’esecuzione dell’immagine gP2S dipende dall’accesso ai database MySQL e MongoDB e a un server LDAP. Per l’ambiente non di produzione, è consigliabile eseguire tutte queste dipendenze come applicazioni Docker multi-contenitore insieme all’applicazione gP2S. Per renderlo senza soluzione di continuità, è stato preparato e fornito un file di docker-compose (https://github.com/arohou/gP2S/blob/master/docker-compose.yml) che include tutte le configurazioni necessarie dell’ambiente finale nel repository gP2S GitHub (https://github.com/arohou/gP2S). Le seguenti immagini docker sono dipendenze: mysql27, mongodb28, apacheds29.
Nella configurazione predefinita, tutti i dati memorizzati, sia le entità che i file allegati verranno eliminati al momento della rimozione dei contenitori docker. Per conservare i dati, è necessario utilizzare i volumi di docker oppure l’applicazione gP2S deve essere connessa a istanze di database dedicate (MySQL e MongoDB). Il contenitore del server LDAP ApacheDS viene fornito con un utente amministratore preconfigurato (password: secret). Queste credenziali devono essere utilizzate per accedere all’applicazione gP2S quando viene eseguita come servizio Docker. Per gli ambienti di produzione, lo stesso file di composizione docker può essere utilizzato per distribuire gP2S (e altri contenitori, se necessario) come servizi in una piattaforma di orchestrazione del contenitore Docker Swarm.
Il processo completo di esecuzione di gP2S come contenitore Docker, inclusi tutti i dettagli relativi alla corretta configurazione, è descritto nel repository gP2S GitHub e tratta i seguenti argomenti:
• Esecuzione dell’applicazione gP2S dockerizzata con tutte le dipendenze.
• Accesso all’applicazione gP2S, al database e a LDAP.
• Aggiornamento del servizio gP2S con una nuova versione.
• Rimozione dell’applicazione gP2S.
• Configurazione della persistenza dei dati.
• Connessione dell’applicazione gP2S dockerizzata a database dedicati o a un server LDAP.
• Dettagli di configurazione
Applicazione Java autonoma
Un’altra opzione per eseguire l’applicazione gP2S è compilare un pacchetto Java autonomo. Questo approccio dovrebbe essere adottato se non è possibile eseguire contenitori Docker. La creazione dell’applicazione gP2S richiede l’installazione di un Kit di sviluppo Java versione 8 o successiva. L’intero processo di compilazione è gestito dallo strumento Maven, fornito nella base di codice nel repository GitHub. La configurazione di compilazione è preparata per compilare prima la parte frontend, quindi copiarla in origini back-end e quindi compilarla come applicazione finale. In questo modo, non è necessario installare altri strumenti o librerie per preparare un pacchetto gP2S pienamente funzionante. Per impostazione predefinita, il risultato della compilazione è un pacchetto JAR (archiviato localmente) e un’immagine Docker (spinta al repository configurato nel file pom.xml Maven). È importante ricordare che le informazioni necessarie per connettersi a sistemi esterni (database e server LDAP) devono essere fornite in un file di configurazione corretto prima della costruzione del pacchetto.
Una volta creato il pacchetto JAR gP2S, contiene tutte le dipendenze e le informazioni di configurazione necessarie per eseguire l’applicazione, incluso il server applicazioni Tomcat che ospita il sistema. Se il pacchetto è stato creato con più file di configurazione, può essere eseguito in diverse modalità senza ricostruzione.
Il repository gP2S GitHub include una descrizione completa del processo di creazione ed esecuzione di gP2S come applicazione autonoma e tratta i seguenti argomenti:
• Costruire gP2S utilizzando lo strumento Maven
• Creazione e gestione con database incorporati
• Creazione ed esecuzione con dipendenze distribuite come contenitori docker
• Costruire e gestire con database dedicati
• Configurazione dell’autenticazione
Se utilizzato correttamente e in modo coerente, gP2S aiuta a ottenere una corretta tenuta dei record di metadati di alta qualità applicando la registrazione di metadati sperimentali critici utilizzando modelli di dati strutturati e vocabolari definiti, ma il valore aggiunto di questo è pienamente realizzato solo quando si raggiunge un alto livello di conformità in laboratorio. Il protocollo di cui sopra non copre come raggiungere questo obiettivo. La Corte ha riscontrato che una tecnica efficace di applicazione consiste nel far sì che gli operatori del microscopio si rifiutassero di raccogliere dati su griglie non registrate in gP2S. Ciò ha portato la conformità molto rapidamente e ha gettato le basi per l’emergere, nei mesi successivi, di un ampio corpus di dettagli sperimentali dettagliati e accurati e memoria aziendale. Dopo alcuni mesi di utilizzo, il valore del corpus di metadati memorizzati in gP2S è diventato così ovvio per la maggior parte degli utenti che la conformità è rimasta elevata senza un intervento esplicito.
Sfruttare appieno questa memoria collettiva richiede che i metadati memorizzati in gP2S siano accessibili a sistemi esterni e facilmente associati ai dati sperimentali (micrografie) e ai risultati (mappe e modelli). Il protocollo di cui sopra non descrive come integrare gP2S con altri sistemi informatici e di elaborazione dei dati. Le più semplici sono potenziali integrazioni tramite l’API REST back-end di gP2S, che non richiedono alcuna modifica di gP2S. Ad esempio, ogni computer che controlla i rilevatori di raccolta dati esegue uno script che esegue periodicamente una query sull’endpoint di gP2S “getItemByMicroscope” sotto il controller REST di gestione delle sessioni di microscopia, per verificare se una sessione di microscopia è in corso al microscopio. In tal caso, lo script recupera da gP2S il nome appropriato della directory di archiviazione dei dati (come configurato nella pagina Impostazioni, vedere sopra) e crea una directory nel dispositivo di archiviazione dati locale utilizzando questo nome. Ciò garantisce la denominazione sistematica delle directory di archiviazione dei dati e riduce il rischio di errori dovuti agli errori di battitura.
Sebbene siano stati commentati alla fonte della versione pubblica di gP2S, sono possibili anche ulteriori integrazioni che coinvolgono gP2S che consumano dati di sistemi esterni. Nel nostro laboratorio, la nostra distribuzione di gP2S si integra con (i) un sistema di gestione dei progetti, in modo che ogni progetto configurato in gP2S possa essere collegato a un progetto di portfolio a livello aziendale e i metadati del portfolio possano essere visualizzati all’interno di gP2S; ii un sistema di registrazione delle proteine, in modo che ogni proteina aggiunta al gP2S sia collegata, tramite un identificatore immagazzinato localmente, a una serie completa di registrazioni che dettaglino la provenienza della proteina, includere dettagli sulla biologia molecolare, il sistema di espressione e la purificazione pertinenti; (iii) un sistema di gestione dei composti di piccole molecole, che consente a gP2S di visualizzare informazioni chiave su ciascun ligando, come la sua struttura chimica. Le modifiche al codice necessarie per abilitare queste integrazioni sono descritte nella sezione “Integrazione” del documento README-BUILD.md disponibile nel repository gP2S (https://github.com/arohou/gP2S).
La versione corrente di gP2S ha dei limiti, il primo dei quali è il modello di dati eccessivamente semplicistico e il frontend per la deposizione della struttura (modello). Questo è stato intenzionalmente lasciato in uno stato “barebones” nella versione rilasciata di gP2S perché una funzione di deposizione e convalida della struttura a tutti gli effetti è attualmente in fase di sviluppo insieme al supporto per la cristallografia a raggi X. Un’altra decisione di progettazione è stata di non implementare alcun sistema di privilegi o autorizzazioni: tutti gli utenti in gP2S hanno uguale accesso alle sue funzionalità e ai suoi dati. Ciò può rendere una scelta sbagliata per le strutture che servono gruppi di utenti con interessi concorrenti e requisiti di riservatezza, ma non è stata una preoccupazione per la nostra struttura.
Lo sviluppo della nostra versione internamente di gP2S è in corso ed è nostra speranza che la versione open source descritta qui sia utile ad altri gruppi crioEM e che alcuni possano contribuire a suggerimenti o miglioramenti del codice in futuro. I futuri sviluppi di alto valore potrebbero ad esempio concentrarsi sulle integrazioni con apparecchiature di laboratorio (robot di vetrificazione, microscopi elettronici), software (ad esempio per raccogliere metadati di elaborazione delle immagini) e repository pubblici esterni (ad esempio per facilitare le deposizioni di strutture).
La raccolta sistematica di metadati di alta qualità abilitata dall’uso di routine di gP2S in laboratorio e nella struttura crioEM può avere un impatto significativo e positivo sulla capacità di perseguire più progetti in parallelo per un periodo di anni. Con l’istituzione di gruppi e strutture crioEM sempre più condivisi e centralizzati, prevediamo che la necessità di sistemi di gestione delle informazioni come gP2S continuerà a crescere.
The authors have nothing to disclose.
Gli autori ringraziano tutti gli altri membri del team di sviluppo gP2S che hanno lavorato al progetto sin dalla sua nascita: 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 e Artur Kusak. Ringraziamo anche Raymond Ha e Claudio Ciferri per aver contribuito a assemblare il team e a plasmare il progetto.