gP2S er en webapplikation til sporing af kryoEM-eksperimenter. Dens vigtigste funktioner er beskrevet, ligesom de trin, der kræves for at installere og konfigurere applikationen. Når det er konfigureret, giver applikationen en mulighed for nøjagtigt at registrere metadata, der er forbundet med negative plet- og kryoEM-eksperimenter.
Kryogene elektronmikroskopi (cryoEM) er blevet en integreret del af mange lægemiddelopdagelsesprojekter, fordi krystallografi af proteinmålet ikke altid er opnåeligt, og cryoEM giver et alternativt middel til at understøtte strukturbaseret liganddesign. Når der beskæftiger sig med et stort antal forskellige projekter, og inden for hvert projekt et potentielt stort antal ligand-protein co-strukturer, nøjagtig registrering hurtigt bliver udfordrende. Mange eksperimentelle parametre er indstillet for hvert mål, herunder ved prøveforberedelsen, gitterforberedelse og mikroskopistadier. Derfor kan nøjagtig registrering være af afgørende betydning for at muliggøre langsigtet reproducerbarhed og for at lette effektivt teamwork, især når trin i cryoEM-arbejdsgangen udføres af forskellige operatører. For at hjælpe med at håndtere denne udfordring udviklede vi et webbaseret informationsstyringssystem til cryoEM, kaldet gP2S.
Ansøgningen holder styr på hvert forsøg, fra prøve til endelig atommodel, i forbindelse med projekter, en liste, som opretholdes i ansøgningen, eller eksternt i et separat system. Brugerdefinerede styrede ordforråd for forbrugsvarer, udstyr, protokoller og software hjælper med at beskrive hvert trin i cryoEM-arbejdsgangen på en struktureret måde. gP2S kan i vid udstrækning konfigureres og kan, afhængigt af teamets behov, eksistere som et selvstændigt produkt eller være en del af et bredere økosystem af videnskabelige applikationer, der via REST API’er integreres med projektstyringsværktøjer, applikationer, der sporer produktionen af proteiner eller af små molekyler, eller applikationer, der automatiserer dataindsamling og -lagring. Brugere kan registrere oplysninger om hver gitter- og mikroskopisession, herunder vigtige eksperimentelle metadata og parameterværdier, og afstamningen af hver eksperimentel artefakt (prøve, gitter, mikroskopisession, kort osv.) registreres. gP2S fungerer som en cryoEM eksperimentel arbejdsgangsarrangør, der muliggør nøjagtig registrering for teams og er tilgængelig under en open source-licens.
Informationsstyring på cryoEM-faciliteter
Fra og med 2014 er antallet af kryogene elektronmikroskopi (kryoEM)1-faciliteter vokset eksplosivt, med mindst 300 avancerede systemer installeret rundt om i verden2, herunder i en række farmaceutiske virksomheder, hvilket afspejler en voksende rolle for cryoEM i lægemiddelforskning3. Disse faciliteters opgaver og deres krav til datasporing og -styring erforskellige 4. Nogle, for eksempel nationale cryoEM-centre, har til opgave at modtage EM-net, indsamle datasæt og returnere data til brugerne til strukturbestemmelse, måske efter en automatiseret billedbehandling. I sådanne anlæg er sporing af nettets herkomst, dets tilknytning til et brugerforslag eller tilskud og afstamning fra gitter til datasæt afgørende, men andre faktorer, såsom metoden til rensning af proteinprøven eller den endelige strukturbestemmelsesproces, er mindre eller slet ikke relevante. I andre faciliteter, såsom lokale akademiske faciliteter, er hver slutbruger ansvarlig for at udarbejde deres egne prøver og net, gennemføre mikroskopi, styre de rå data og dens behandling og offentliggøre resultaterne. Der er ikke noget strengt behov for metadatasporing fra en sådan facilitets side, fordi denne rolle opfyldes af slutbrugeren eller dennes principal investigator.
I vores kryoEM-facilitet centraliseres håndtering og optimering af prøver, gitre, dataindsamlings- og behandlingsprotokoller og resultater (kort, modeller) på tværs af mange projekter på en lille gruppe praktikere. Dette giver udfordringer i eksperimentel (meta)datastyring. Den eksperimentelle afstamning af strukturer, fra atommodel helt tilbage til den nøjagtige identitet af proteiner og ligands, via gitterforberedelsesparametre og dataindsamlingsprotokoller, skal registreres og bevares nøjagtigt. Disse metadata skal gøres tilgængelige for en række menneskelige operatorer. For eksempel kan en person, der laver billedbehandling, have brug for at vide, hvilken konstruktion af et protein der blev brugt, og hvad billedparametrene var, selvom de hverken rensede proteinet eller selv indsamlede cryoEM-dataene; informatiksystemer såsom automatiserede datastyrings dæmoner skal identificere det projekt, som et mikroskop i øjeblikket indsamler data for, for korrekt og systematisk at tildele mappenavne.
Der findes flere informationsstyringssystemer til støtte for cryoEM-faciliteter. Måske mest komplette blandt dem er EMEN25, som kombinerer funktioner i en elektronisk lab notebook, et information management system, og nogle elementer i en forretningsproces management værktøj. Bruges på mange synkrotroner, ISPyB6, oprindeligt bygget til at understøtte røntgenstrålelinjer til krystallografi, understøtter nu også cryoEM dataindsamling. Scipion7 er en rig og kraftfuld indpakning omkring billedbehandling pakker, som giver brugerne mulighed for at optage billedbehandling arbejdsgange og dele dem, for eksempel via det offentlige depot EMPIAR8,9, og er også integreret med ISPyB at muliggøre on-the-fly cryoEM databehandling.
Her beskriver vi gP2S (for Genentech Protein to Structure), et moderne og let cryoEM information management system bygget til at understøtte arbejdsgangen fra renset protein og lille molekyle ligand frem til den endelige atommodel.
Oversigt over gP2S
gP2S er et brugervenligt webbaseret cryoEM-informationsstyringssystem, der letter nøjagtig registrering af cryoEM-laboratorier og multibruger- og multiprojektfaciliteter. Følgende enheder, deres relationer og tilknyttede metadata spores: projekter, udstyr, forbrugsvarer, protokoller, prøver, gitre, mikroskopisessioner, billedbehandlingssessioner, kort og atommodeller. Brugerne kan også tilføje fritekstkommentarer, herunder eventuelt vedhæftede filer, hvilket giver mulighed for omfattende anmærkninger af alle objekter, der er registreret i gP2S. Frontend er designet til at lette brugen med touchscreen-enheder og testet grundigt på 12,9 “iPad Pros, hvilket gør det muligt at bruge gP2S på laboratoriet bænk, mens du forbereder prøver og gitre (Figur 1), samt ved computeren, når du betjener mikroskopet, behandling af billeder eller deponering modeller. Hver side i frontend har til formål at reducere manuel indtastning af data ved at forudindstille parametre til fornuftige standardværdier, når det er muligt.
Backend af gP2S har en række HVILE API-slutpunkter (REpresentational State Transfer Application Programming Interface), hvilket gør det muligt at integrere gP2S i eksisterende arbejdsprocesser og scripts. Datamodellen er designet til at muliggøre nøjagtig registrering af negative pletter og kryoEM-arbejdsprocesser, herunder forgrening, for eksempel med en prøve, der bruges på flere gitre, data fra flere mikroskopisessioner, der flettes ind i en enkelt databehandlingssession, eller en databehandlingssession, der giver flere kort.
Systemarkitektur
gP2S er et klassisk tredelt program (Figur 2). I denne modulopbyggede arkitektur er systemet opdelt i tre separate lag, der hver især er ansvarlige for at udføre forskellige opgaver, og hver udskiftelig eller modificerbar uafhængigt af de andre. (1) Præsentationslaget (eller frontend) giver brugeren adgang via webbrowser (grundigt testet med Chrome og Safari), giver mulighed for at oprette og ændre arbejdsgangselementer (herunder datavalidering) og viser eksperimentelle data som individuelle enheder, projektbaserede lister og fulde arbejdsprocesrapporter. (2) Tjenestelaget (eller backend) fungerer som et mellemliggende lag mellem brugergrænsefladen og lagringssystemet – det har kerneforretningslogik, udsætter den tjeneste-API, der bruges af frontend, integreres med datalagring og LDAP (Lightweight Directory Access Protocol) system til brugergodkendelse og danner grundlag for yderligere integration med eksterne systemer. (3) Persistenslaget (dataadgang) er ansvarligt for lagring af eksperimentelle data, brugerkommentarer og vedhæftede filer.
Nøgleteknologier og -rammer
For at lette udviklingen, opførelsen og vedligeholdelsen af gP2S-applikationen blev der anvendt flere teknologier og rammer i projektet. De vigtigste er: Vue.js 2.4.210 for frontend og SpringBoot 1,311 med indlejret Tomcat 8 server til backend. Programmet bruger MySQL 5.7- og MongoDB 4.0.6-databaser til lagring og LDAP12 til godkendelse. Som standard leveres og installeres alle disse komponenter som ét program.
I alt bruger applikationen hundredvis af forskellige biblioteker enten direkte eller indirekte. De mest fremtrædende er anført i tabel 1.
Datamodel
Der kan skelnes mellem tre typer enheder i gP2S-datamodellen (figur 3): arbejdsgangsenheder relateret til data indsamlet under forsøg (f.eks. prøver eller mikroskopisessioner); udstyr og protokolenheder, der beskriver data, der er fælles for alle projekter (f.eks. mikroskoper eller vitrifikationsprotokoller) andre enheder, der spiller støttende eller tekniske roller i systemet (f.eks. kommentarer eller standardværdier).
Roden af arbejdsprocesdatatræet er objektet Project. Hvert projekt består af en række proteiner og/eller ligands, der er byggesten til oprettelse af sample-enheder. Hvert eksempel kan bruges til at oprette flere gitre, som igen bruges i mikroskopisessioner (et gitter pr. mikroskopisession). Sidstnævnte er tildelt behandlingssessioner, der kan give et eller flere kort. Den sidste enhed i træet er atommodellen, der er oprettet ved hjælp af et eller flere kort. Som følge heraf er alle arbejdsgangsrelaterede objekter, fra protein til model, altid bundet til et bestemt projekt via dets forfædre. Et sådant design skaber dataaggregater, der er nemme at behandle enten ved frontend-modulet eller ved hjælp af eksterne systemer ved hjælp af API’en.
Ud over arbejdsprocesdata er der objekter, der beskriver udstyr, der bruges i eksperimenter eller protokoller, der blev fulgt under forberedelse af gitre. Det er en forudsætning at definere disse objekter for at oprette eksperimentelle arbejdsprocesobjekter, f.eks.
Den sidste type dataenhed, der samlet kaldes “Andet”, bruges til tekniske formål (f.eks. vedhæftede filer eller standardværdier). Denne kategori omfatter kommentarobjekter, der kan knyttes til alle arbejdsprocesser eller udstyrs-/protokolobjekter.
Softwaretilgængelighed
Open source-versionen af gP2S er tilgængelig under en Apache License Version 2.026fra https://github.com/arohou/gP2S. Et Docker-billede til at køre gP2S er tilgængeligt fra https://hub.docker.com/r/arohou/gp2s. En lukket kildeafdeling af gP2S er under fortsat udvikling hos Roche &Genentech.
Kørsel af gP2S-programmet
Der er to måder at køre gP2S på: som docker-objektbeholder eller som et enkeltstående Java-program. Det optimale valg afhænger af destinationsinstallationsmiljøet. Hvis for eksempel muligheden for at tilpasse eller forbedre koden, så den passer til brugernes specifikke behov, ønskes, skal hele applikationen først genbygges. I dette tilfælde anbefales det at køre gP2S som et enkeltstående program.
Havnecontainer
Den nemmeste måde at begynde at arbejde med gP2S-programmet på er at køre det som en Docker-tjeneste. Til dette formål er et dedikeret Docker-billede blevet forberedt og offentliggjort i Docker Hub-lageret (“https://hub.docker.com/r/arohou/gp2s”). Kørsel af gP2S-afbildningen afhænger af adgangen til MySQL- og MongoDB-databaser og til en LDAP-server. I forbindelse med ikke-produktionsmiljø anbefales det at køre alle disse afhængigheder som Docker-programmer med flere containere sammen med gP2S-programmet. For at gøre dette problemfrit er der udarbejdet og leveret en docker-compose-fil (https://github.com/arohou/gP2S/blob/master/docker-compose.yml), der indeholder alle nødvendige konfigurationer af det endelige miljø, i gP2S GitHub-lageret (https://github.com/arohou/gP2S). Følgende docker billeder er afhængigheder: mysql27, mongodb28, apacheds29.
I standardkonfigurationen slettes alle gemte data, både objekter og vedhæftede filer, når dockercontainerne fjernes. For at opbevare dataene skal der enten bruges dockervolumener, eller gP2S-applikationen skal være forbundet med dedikerede databaseforekomster (MySQL og MongoDB). ApacheDS LDAP-serverbeholderen leveres med en forudkonfigureret administratorbruger (adgangskode: hemmelighed). Disse legitimationsoplysninger skal bruges til at logge på gP2S-programmet, når det køres som en Docker-tjeneste. Til produktionsmiljøer kan den samme docker-komponere fil bruges til at implementere gP2S (og andre beholdere, hvis det er nødvendigt) som tjenester til en Docker Swarm container orkestreringsplatform.
Den fulde proces med at køre gP2S som en Docker-beholder, herunder alle detaljer om korrekt konfiguration, er beskrevet i gP2S GitHub-lageret og dækker følgende emner:
• Kørsel af det dockeriserede gP2S-program med alle afhængigheder.
• Adgang til gP2S-programmet, databasen og LDAP.
• Opdatering af gP2S-tjenesten med en ny version.
• Fjernelse af gP2S-program.
• Konfiguration af datavedholdenhed.
• Tilslutning af det dockeriserede gP2S-program til dedikerede databaser eller en LDAP-server.
• Oplysninger om konfiguration
Enkeltstående Java-program
En anden mulighed for at køre gP2S-applikationen er at opbygge en selvstændig Java-pakke. Denne fremgangsmåde bør anvendes, hvis det ikke er muligt at køre Docker-containere. Opbygning af gP2S-programmet kræver installation af en Java Development Kit version 8 eller nyere. Hele byggeprocessen administreres af maven-værktøjet, som leveres i kodebasen i GitHub-lageret. Build konfiguration er parat til at bygge frontend del først, derefter kopiere den til backend kilder, og derefter bygge det som en endelig ansøgning. På denne måde er der ingen grund til at installere andre værktøjer eller biblioteker for at forberede en fuldt fungerende gP2S-pakke. Resultatet af buildet er som standard en JAR-pakke (gemt lokalt) og Docker-billede (skubbet til lageret konfigureret i Maven pom.xml-filen). Det er vigtigt at huske, at de oplysninger, der kræves for at oprette forbindelse til eksterne systemer (databaser og LDAP-server), skal angives i en korrekt konfigurationsfil, før pakken bygges.
Når gP2S JAR-pakken er oprettet, indeholder den alle afhængigheder og konfigurationsoplysninger, der er nødvendige for at køre programmet, herunder Tomcat-applikationsserveren, der er vært for systemet. Hvis pakken er bygget med flere konfigurationsfiler, kan den køres i forskellige tilstande uden at genopbygge.
GP2S GitHub-lageret indeholder en komplet beskrivelse af processen med at opbygge og køre gP2S som et enkeltstående program og dækker følgende emner:
• Opbygning af gP2S ved hjælp af mavenværktøjet
• Opbygning og kørsel med integrerede databaser
• Opbygning og kørsel med afhængigheder, der er installeret som dockercontainere
• Opbygning og kørsel med dedikerede databaser
• Konfiguration af godkendelse
Når gP2S bruges korrekt og konsekvent, hjælper det med at opnå korrekt registrering af metadata af høj kvalitet ved at håndhæve registreringen af kritiske eksperimentelle metadata ved hjælp af strukturerede datamodeller og definerede ordforråd, men merværdien af dette realiseres kun fuldt ud, når der opnås en høj grad af overholdelse i laboratoriet. Ovenstående protokol dækker ikke, hvordan man opnår dette. Vi konstaterede, at en effektiv håndhævelsesteknik var at få mikroskopoperatører til at nægte at indsamle data om net, der ikke er registreret i gP2S. Dette drev overholdelse op meget hurtigt og lagde grunden til fremkomsten i løbet af de følgende måneder af en stor mængde detaljerede og nøjagtige eksperimentelle detaljer og virksomhedshukommelse. Efter et par måneders brug blev værdien af det korpus af metadata, der er gemt i gP2S, så indlysende for de fleste brugere, at overholdelse forblev høj uden eksplicit indgriben.
Fuld udnyttelse af denne kollektive hukommelse kræver, at de metadata, der er gemt i gP2S, er tilgængelige for eksterne systemer og let forbundet med de eksperimentelle data (mikrografer) og resultater (kort og modeller). Ovenstående protokol beskriver ikke, hvordan man integrerer gP2S med andre informatik- og databehandlingssystemer. Mest ligetil er potentielle integrationer via gP2S’s backend REST API, som ikke kræver nogen ændring af gP2S. For eksempel kører hver computer, der kontrollerer vores dataindsamlingsdetektorer, et script, der med jævne mellemrum forespørger gP2S’s slutpunkt “getItemByMicroscope” under mikroskopsessionsstyring REST-controlleren for at kontrollere, om en mikroskopsession er i gang på sit mikroskop. Hvis det er tilfældet, henter scriptet fra gP2S det relevante datalagringsmappenavn (som konfigureret på siden Indstillinger, se ovenfor) og opretter en mappe på den lokale datalagringsenhed ved hjælp af dette navn. Dette sikrer systematisk navngivning af datalagringsmapper og reducerer risikoen for fejl på grund af slåfejl.
Selv om de er blevet kommenteret i kilden til den offentlige version af gP2S, er yderligere integrationer, der involverer gP2S, der forbruger eksterne systemers data, også mulige. I vores laboratorium integreres vores implementering af gP2S med (i) et projektstyringssystem, så hvert projekt, der er konfigureret i gP2S, kan knyttes til et porteføljeprojekt for hele virksomheden, og metadata fra porteføljen kan vises i gP2S; ii) et proteinregistreringssystem, således at hvert protein, der tilsættes gP2S, via en identifikator, der er lagret lokalt, er knyttet til et komplet sæt optegnelser, der beskriver proteinets herkomst, indeholder nærmere oplysninger om den relevante molekylærbiologi, ekspressionssystem og rensning (iii) et lille molekyle sammensatte styringssystem, så gP2S at vise vigtige oplysninger om hver ligand, såsom dens kemiske struktur. De kodeændringer, der er nødvendige for at muliggøre disse integrationer, er beskrevet i afsnittet “Integration” i det README-BUILD.md dokument, der er tilgængeligt fra gP2S-lageret (https://github.com/arohou/gP2S).
Den aktuelle version af gP2S har begrænsninger, hvoraf den første er den alt for forenklede datamodel og frontend for struktur (Model) deposition. Dette blev med vilje efterladt i en “barebones” tilstand i den frigivne version af gP2S, fordi en fuldt udbygget strukturaflejrings- og valideringsfunktion i øjeblikket er under udvikling sammen med støtte til røntgenkrystallografi. En anden designbeslutning var ikke at implementere nogen rettigheds- eller tilladelsessystem: Alle brugere i gP2S har lige adgang til dets funktioner og data. Dette kan gøre det til et dårligt valg for faciliteter, der betjener brugergrupper med konkurrerende interesser og fortrolighedskrav, men var ikke et problem for vores facilitet.
Udvikling af vores in-house version af gP2S er i gang, og det er vores håb, at open source-versionen beskrevet her vil være nyttig for andre cryoEM grupper, og at nogle kan bidrage med forslag, eller kode forbedringer i fremtiden. Fremtidige udviklinger af høj værdi kan f.eks. fokusere på integrationer med laboratorieudstyr (vitrificeringsrobotter, elektronmikroskoper), software (f.eks. til høst af billedbehandlingsmetadata) og eksterne offentlige depoter (f.eks. for at lette strukturaflejring).
Den systematiske indsamling af metadata af høj kvalitet, der aktiveres ved rutinemæssig brug af gP2S i laboratoriet og kryoEM-anlægget, kan have en betydelig, positiv indvirkning på evnen til at retsforfølge flere projekter parallelt over en årrække. Efterhånden som der etableres flere og flere fælles og centraliserede cryoEM-grupper og -faciliteter, forventer vi, at behovet for informationsstyringssystemer som f.eks.
The authors have nothing to disclose.
Forfatterne takker alle de andre medlemmer af gP2S udvikling team, der har arbejdet på projektet siden starten: 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 og Artur Kusak. Vi takker også Raymond Ha og Claudio Ciferri for at hjælpe med at samle teamet og forme projektet.