gP2S er et webprogram for sporing av cryoEM-eksperimenter. Hovedfunksjonene er beskrevet, og det samme er trinnene som kreves for å installere og konfigurere applikasjonen. Når den er konfigurert, lar applikasjonen en nøyaktig registrere metadata knyttet til negative flekk- og kryoEM-eksperimenter.
Kryogene elektronmikroskopi (cryoEM) har blitt en integrert del av mange narkotikaoppdagelsesprosjekter fordi krystallografi av proteinmålet ikke alltid er oppnåelig, og kryoEM gir et alternativt middel for å støtte strukturbasert liganddesign. Når du arbeider med et stort antall forskjellige prosjekter, og i hvert prosjekt et potensielt stort antall ligandprotein-kostrukturer, blir nøyaktig journalføring raskt utfordrende. Mange eksperimentelle parametere er justert for hvert mål, inkludert ved prøvepreparering, rutenettforberedelse og mikroskopistadier. Derfor kan nøyaktig journalføring være avgjørende for å muliggjøre langsiktig reproduserbarhet, og for å lette effektivt teamarbeid, spesielt når trinn i cryoEM-arbeidsflyten utføres av forskjellige operatører. For å hjelpe til med å håndtere denne utfordringen utviklet vi et nettbasert informasjonsstyringssystem for cryoEM, kalt gP2S.
Applikasjonen holder oversikt over hvert eksperiment, fra prøve til endelig atommodell, i sammenheng med prosjekter, en liste som vedlikeholdes i applikasjonen, eller eksternt i et eget system. Brukerdefinerte kontrollerte ordforråd av forbruksvarer, utstyr, protokoller og programvare bidrar til å beskrive hvert trinn i cryoEM-arbeidsflyten på en strukturert måte. gP2S er mye konfigurerbar og, avhengig av teamets behov, kan eksistere som et frittstående produkt eller være en del av et bredere økosystem av vitenskapelige applikasjoner, integrere via REST API-er med prosjektstyringsverktøy, applikasjoner som sporer produksjon av proteiner eller små molekyler ligander, eller applikasjoner som automatiserer datainnsamling og lagring. Brukere kan registrere detaljer om hvert rutenett og mikroskopiøkt, inkludert viktige eksperimentelle metadata og parameterverdier, og slektslinjen til hver eksperimentelle artefakt (prøve, rutenett, mikroskopiøkt, kart, etc.) registreres. gP2S fungerer som en kryoEM eksperimentell arbeidsflytarrangør som muliggjør nøyaktig registrering for team, og er tilgjengelig under en åpen kildekode-lisens.
Informasjonshåndtering ved cryoEM-anlegg
Fra og med 2014 har antallet kryogene elektronmikroskopi (cryoEM)1-anlegg vokst eksplosivt, med minst 300 avanserte systemer installert over hele verden2, inkludert hos en rekke farmasøytiske selskaper, noe som gjenspeiler en voksende rolle for kryoEM i legemiddeloppdagelse3. Oppdragene til disse fasilitetene, og deres krav til datasporing og ledelse, varierer4. Noen, for eksempel nasjonale cryoEM-sentre, er tiltalt for å motta EM-rutenett, samle inn datasett og returnere data til brukerne for strukturbestemmelse, kanskje etter automatisert bildebehandling. I slike anlegg er sporing av opprinnelsen til nettet, dets tilknytning til et brukerforslag eller tilskudd, og avstamningen fra rutenett til datasett avgjørende, men andre faktorer, for eksempel metoden for rensing av proteinprøven eller den endelige strukturbestemmelsesprosessen, er mindre, eller ikke i det hele tatt, relevante. I andre anlegg, som lokale akademiske anlegg, er hver sluttbruker ansvarlig for å forberede sine egne prøver og nett, gjennomføre mikroskopi, administrere rådataene og dens behandling og publisering av resultatene. Det er ikke noe strengt behov for metadatasporing fra en slik fasilitet fordi denne rollen er oppfylt av sluttbrukeren eller deres hovedetterforsker.
I vårt cryoEM-anlegg sentraliseres håndtering og optimalisering av prøver, rutenett, datainnsamlings- og prosesseringsprotokoller og resultater (kart, modeller) på tvers av mange prosjekter til en liten gruppe utøvere. Dette byr på utfordringer innen eksperimentell (meta)datahåndtering. Den eksperimentelle avstamningen av strukturer, fra atommodell helt tilbake til den eksakte identiteten til proteiner og ligander, via nettforberedelsesparametere og datainnsamlingsprotokoller, må fanges nøyaktig og bevares. Disse metadataene må gjøres tilgjengelig for en rekke menneskelige operatører. For eksempel kan det hende at en person som utfører bildebehandling, må vite hvilken konstruksjon av et protein som ble brukt og hva bildeparametrene var, selv om de verken renset proteinet eller samlet inn cryoEM-dataene selv; informatikksystemer som automatiserte daemoner for databehandling må identifisere prosjektet som et mikroskop for tiden samler inn data for å kunne tilordne katalognavn på riktig og systematisk måte.
Flere informasjonsstyringssystemer er tilgjengelige for å støtte cryoEM-anlegg. Kanskje mest komplett blant dem er EMEN25, som kombinerer funksjoner i en elektronisk lab bærbar PC, et informasjonsstyringssystem og noen elementer i et forretningsprosessadministrasjonsverktøy. ISPyB6brukes på mange synkrotroner, opprinnelig bygget for å støtte røntgenstrålene for krystallografi, og støtter nå også cryoEM-datainnsamling. Scipion7 er en rik og kraftig wrapper rundt bildebehandlingspakker, som lar brukerne registrere arbeidsflyter for bildebehandling og dele dem, for eksempel via det offentlige repositoriet EMPIAR8,9, og er også integrert med ISPyB for å muliggjøre kryoem-databehandling på farten.
Her beskriver vi gP2S (for Genentech Protein to Structure), et moderne og lett kryoEM informasjonsstyringssystem bygget for å støtte arbeidsflyten fra renset protein og lite molekylligand til den endelige atommodellen.
Oversikt over gP2S
gP2S er et brukervennlig nettbasert kryoEM informasjonsstyringssystem som letter nøyaktig journalføring for cryoEM-laboratorier og flerbrukerfasiliteter med flere prosjekter. Følgende enheter, deres relasjoner og tilknyttede metadata spores: prosjekter, utstyr, forbruksvarer, protokoller, prøver, rutenett, mikroskopiøkter, bildebehandlingsøkter, kart og atommodeller. Brukere kan også legge til fritekstkommentarer, eventuelt inkludert filvedlegg, noe som gir rik merknad om en hvilken som helst enhet som er registrert i gP2S. Fronten er designet for å lette bruken med berøringsskjermenheter og testet grundig på 12,9″ iPad Pros, noe som gjør det mulig å bruke gP2S på laboratoriebenken mens du forbereder prøver og rutenett (figur 1), samt på datamaskinen når du bruker mikroskopet, behandler bilder eller deponerer modeller. Hver side i fronten tar sikte på å redusere manuell dataregistrering ved å forhåndsinnstille parametere til fornuftige standardverdier når det er mulig.
Backend av gP2S har en rekke REST API (REpresentational State Transfer Application Programming Interface) endepunkter, noe som gjør det mulig å integrere gP2S i eksisterende arbeidsflyter og skript. Datamodellen ble utformet for å tillate nøyaktig registrering av negative flekk- og kryoem-arbeidsflyter, inkludert forgrening, for eksempel med ett utvalg som brukes på flere rutenett, data fra flere mikroskopiøkter som slås sammen til en enkelt databehandlingsøkt, eller en databehandlingsøkt som gir flere kart.
Systemarkitektur
gP2S er et klassisk trelags program (figur 2). I denne modulære arkitekturen er systemet delt inn i tre separate lag, som hver er ansvarlige for å utføre distinkte oppgaver, og hver utskiftbar eller modifiserbar uavhengig av de andre. (1) Presentasjonslaget (eller frontend) gir brukertilgang via nettleser (grundig testet med Chrome og Safari), gjør det mulig å opprette og endre arbeidsflytelementer (inkludert datavalidering), og viser eksperimentelle data som individuelle enheter, prosjektbaserte lister og fulle arbeidsflytrapporter. (2) Tjenestelaget (eller backend) fungerer som et mellomliggende lag mellom brukergrensesnittet og lagringssystemet – det har kjerne forretningslogikk, eksponerer tjeneste-API-en som brukes av frontend, integreres med datalagring og LDAP (Lightweight Directory Access Protocol) system for brukerautentisering, og gir grunnlag for ytterligere integrasjon med eksterne systemer. (3) Utholdenhetslaget (datatilgang) er ansvarlig for lagring av eksperimentelle data, brukerkommentarer og filvedlegg.
Viktige teknologier og rammeverk
For å legge til rette for utvikling, bygging og vedlikehold av gP2S-applikasjonen ble det brukt flere teknologier og rammeverk i prosjektet. De viktigste er: Vue.js 2.4.210 for frontend og SpringBoot 1.311 med innebygd Tomcat 8-server for backend. Programmet bruker MySQL 5.7- og MongoDB 4.0.6-databaser for lagring og LDAP12 for godkjenning. Som standard leveres og distribueres alle disse komponentdelene som ett program.
Totalt bruker applikasjonen hundrevis av forskjellige biblioteker enten direkte eller indirekte. De mest fremtredende er oppført i Tabell 1.
Datamodell
Tre typer enheter kan skilles fra gP2S-datamodellen (figur 3): arbeidsflytenheter relatert til data som samles inn under eksperimenter (f.eks. prøver eller mikroskopiøkter); utstyrs- og protokollenheter som beskriver data som er vanlige på tvers av alle prosjekter (f.eks. mikroskoper eller vitrifiseringsprotokoller); andre enheter som spiller støttende eller tekniske roller i systemet (f.eks. kommentarer eller standardverdier).
Roten til arbeidsflytdatatreet er Prosjekt-enheten. Hvert prosjekt består av en rekke proteiner og/eller ligander som er byggesteiner for oppretting av utvalgsenheter. Hver prøve kan brukes til å lage flere rutenett som igjen brukes i mikroskopiøkter (ett rutenett per mikroskopiøkt). Sistnevnte tilordnes behandlingsøkter som kan gi én eller flere kart. Den siste enheten i treet er atommodellen, opprettet ved hjelp av ett eller flere kart. Følgelig er hver arbeidsflytrelatert enhet, fra Protein til Modell, alltid bundet til et bestemt prosjekt via sine forfedre. Slik design skaper datamengder som er enkle å behandle enten av frontend-modulen eller av eksterne systemer som bruker API-en.
I tillegg til arbeidsflytdata finnes det enheter som beskriver utstyr som brukes i eksperimenter eller protokoller som ble fulgt under klargjøring av rutenett. Definering av disse enhetene er en forutsetning for å opprette eksperimentelle arbeidsflytenheter som Rutenett, Mikroskopi og Prosesseringsøkter.
Den siste typen dataenhet, samlet kalt “Annet”, brukes til tekniske formål (f.eks. filvedlegg eller standardverdier). Denne kategorien inneholder kommentarenheter som kan kobles til alle arbeidsflyt- eller utstyrs-/protokollenheter.
Tilgjengelighet av programvare
Åpen kildekode-versjonen av gP2S er tilgjengelig under en Apache-lisensversjon 2.026, fra https://github.com/arohou/gP2S. Et Docker-bilde for å kjøre gP2S er tilgjengelig fra https://hub.docker.com/r/arohou/gp2s. En lukket kildegren av gP2S er under fortsatt utvikling hos Roche &Genentech.
Kjøre gP2S-programmet
Det er to måter å kjøre gP2S på: som en dockerbeholder eller som et frittstående Java-program. Det optimale valget avhenger av måldistribusjonsmiljøet. Hvis for eksempel muligheten til å tilpasse eller forbedre koden som passer til spesifikke behov for brukerne, er ønsket, må hele applikasjonen bygges på nytt først. I dette tilfellet kan det anbefales å kjøre gP2S som et frittstående program.
Docker-beholder
Den enkleste måten å begynne å jobbe med gP2S-programmet på, er å kjøre det som en Docker-tjeneste. Til dette formålet er et dedikert Docker-bilde utarbeidet og publisert i Docker Hub-repositoriet (“https://hub.docker.com/r/arohou/gp2s”). Kjøring av gP2S-bildet avhenger av tilgang til MySQL- og MongoDB-databaser, og til en LDAP-server. For ikke-produksjonsmiljø anbefales det å kjøre alle disse avhengighetene som Docker-programmer med flere beholdere sammen med gP2S-programmet. For å gjøre dette sømløst er det utarbeidet og levert en docker-komponeringsfil (https://github.com/arohou/gP2S/blob/master/docker-compose.yml) som inkluderer alle nødvendige konfigurasjoner av det endelige miljøet, og som finnes i gP2S GitHub-repositoriet (https://github.com/arohou/gP2S). Følgende docker-bilder er avhengigheter: mysql27, mongodb28, apacheds29.
I standardkonfigurasjonen slettes alle lagrede data, både enheter og filvedlegg ved fjerning av dockerbeholderne. For å beholde dataene, bør enten dockervolumer brukes, eller gP2S-applikasjonen skal være koblet til dedikerte databaseforekomster (MySQL og MongoDB). ApacheDS LDAP-serverbeholderen leveres med en forhåndskonfigurert administratorbruker (passord: hemmelig). Disse legitimasjonsbeskrivelsene bør brukes til å logge på gP2S-programmet når det kjøres som en Docker-tjeneste. For produksjonsmiljøer kan den samme docker-komponeringsfilen brukes til å distribuere gP2S (og andre beholdere om nødvendig) som tjenester til en Docker Swarm container orkestreringsplattform.
Hele prosessen med å kjøre gP2S som en Docker-beholder, inkludert alle detaljer om riktig konfigurasjon, er beskrevet i gP2S GitHub-repositoriet og dekker følgende emner:
• Kjøre det dokkingprogrammet gP2S med alle avhengigheter.
• Tilgang til gP2S-applikasjonen, databasen og LDAP.
• Oppdaterer gP2S-tjenesten med en ny versjon.
• Fjerne gP2S-programmet.
• Konfigurere vedvarende data.
• Koble det dockeriserte gP2S-programmet til dedikerte databaser eller en LDAP-server.
• Konfigurasjonsdetaljer
Frittstående Java-program
Et annet alternativ for å kjøre gP2S-applikasjonen er å bygge en selvstendig Java-pakke. Denne tilnærmingen bør tas hvis det ikke er mulig å kjøre Docker-beholdere. Å bygge gP2S-applikasjonen krever installasjon av en Java Development Kit versjon 8 eller nyere. Hele byggeprosessen administreres av Maven-verktøyet, som leveres i kodebasen i GitHub-repositoriet. Byggekonfigurasjonen er forberedt på å bygge frontdelen først, deretter kopiere den til bakkilder og deretter bygge den som et endelig program. På denne måten er det ikke nødvendig å installere andre verktøy eller biblioteker for å forberede en fullt fungerende gP2S-pakke. Som standard er resultatet av builden en JAR-pakke (lagret lokalt) og Docker-bilde (sendt til depotet som er konfigurert i Maven pom.xml-filen). Det er viktig å huske at informasjon som kreves for å koble til eksterne systemer (databaser og LDAP-server), må finnes i en riktig konfigurasjonsfil før pakken bygges.
Når gP2S JAR-pakken er opprettet, inneholder den alle avhengigheter og konfigurasjonsinformasjon som trengs for å kjøre programmet, inkludert Tomcat-programserveren som er vert for systemet. Hvis pakken ble bygget med flere konfigurasjonsfiler, kan den kjøres i forskjellige modi uten å gjenoppbygge.
gP2S GitHub-repositoriet inneholder en fullstendig beskrivelse av prosessen med å bygge og kjøre gP2S som et frittstående program og dekker følgende emner:
• Bygge gP2S ved hjelp av Maven-verktøyet
• Bygge og kjøre med innebygde databaser
• Bygge og kjøre med avhengigheter utplassert som dockerbeholdere
• Bygge og kjøre med dedikerte databaser
• Konfigurere godkjenning
Når det brukes riktig og konsekvent, bidrar gP2S til å oppnå riktig registrering av metadata av høy kvalitet ved å håndheve registreringen av kritiske eksperimentelle metadata ved hjelp av strukturerte datamodeller og definerte ordforråd, men merverdien av dette er bare fullt realisert når et høyt samsvarsnivå oppnås i laboratoriet. Protokollen ovenfor dekker ikke hvordan du oppnår dette. Vi fant ut at en effektiv håndhevelsesteknikk var å få mikroskopoperatører til å nekte å samle inn data på rutenett som ikke er registrert i gP2S. Dette drev samsvaret opp veldig raskt og la grunnlaget for fremveksten, i løpet av de følgende månedene, av en stor mengde detaljerte og nøyaktige eksperimentelle detaljer og bedriftsminne. Etter noen måneders bruk ble verdien av korpuset av metadata lagret i gP2S så åpenbar for de fleste brukere at overholdelse forble høy uten eksplisitt inngrep.
Fullt utnytte dette kollektive minnet krever at metadataene som er lagret i gP2S være tilgjengelige for eksterne systemer og lett forbundet med eksperimentelle data (mikrografer) og resultater (kart og modeller). Protokollen ovenfor beskriver ikke hvordan du integrerer gP2S med andre informatikk- og databehandlingssystemer. Det mest enkle er potensielle integrasjoner via gP2S’s backend REST API, som ikke krever noen modifikasjon av gP2S. Hver datamaskin som kontrollerer datainnsamlingsdetektorene våre, kjører for eksempel et skript som regelmessig spør gP2S’s endepunkt “getItemByMicroscope” under REST-kontrolleren for behandling av mikroskopiøkter, for å sjekke om en mikroskopøkt pågår på mikroskopet. I så fall henter skriptet fra gP2S det riktige navnet på datalagringsmappen (som konfigurert på Innstillinger-siden, se ovenfor), og oppretter en mappe på den lokale datalagringsenheten ved hjelp av dette navnet. Dette sikrer systematisk navngivning av datalagringskataloger og reduserer risikoen for feil på grunn av skrivefeil.
Selv om de har blitt kommentert i kilden til den offentlige versjonen av gP2S, er det også mulig med ytterligere integrasjoner som involverer gP2S-forbruk av eksterne systemers data. I laboratoriet vårt integreres vår distribusjon av gP2S med (i) et prosjektstyringssystem, slik at hvert prosjekt som er konfigurert i gP2S, kan kobles til et porteføljeprosjekt for hele selskapet, og metadata fra porteføljen kan vises i gP2S; (ii) et proteinregistreringssystem, slik at hvert protein som legges til gP2S er koblet, via en identifikator lagret lokalt, til et komplett sett med poster som beskriver opprinnelsen til proteinet, inkluderer detaljer om relevant molekylærbiologi, uttrykkssystem og rensing; (iii) et lite molekyl sammensatt styringssystem, slik at gP2S kan vise nøkkelinformasjon om hver ligand, for eksempel den kjemiske strukturen. Kodeendringene som er nødvendige for å aktivere disse integreringene, er beskrevet i delen Integrasjon i README-BUILD.md dokumentet som er tilgjengelig fra gP2S-repositoriet (https://github.com/arohou/gP2S).
Den nåværende versjonen av gP2S har begrensninger, først blant annet den altfor forenklede datamodellen og frontend for struktur (modell) avsetning. Dette ble med vilje etterlatt i en “barebones” tilstand i den utgitte versjonen av gP2S fordi en fullverdig strukturavsetnings- og valideringsfunksjon for tiden er under utvikling sammen med støtte for røntgenkrystallografi. En annen utformingsavgjørelse var å ikke implementere noen privilegier eller tillatelsessystem: Alle brukere i gP2S har lik tilgang til funksjonene og dataene. Dette kan gjøre det til et dårlig valg for anlegg som betjener brukergrupper med konkurrerende interesser og konfidensialitetskrav, men som ikke var en bekymring for anlegget vårt.
Utviklingen av vår interne versjon av gP2S pågår, og det er vårt håp at åpen kildekode-versjonen som er beskrevet her, vil være nyttig for andre cryoEM-grupper, og at noen kan bidra med forslag, eller kodeforbedringer i fremtiden. Fremtidige utviklinger av høy verdi kan for eksempel fokusere på integrasjoner med laboratorieutstyr (vitrifiseringsroboter, elektronmikroskoper), programvare (f.eks. for å høste metadata for bildebehandling) og eksterne offentlige depoter (f.eks. for å lette strukturavsetninger).
Den systematiske innsamlingen av metadata av høy kvalitet som aktiveres ved rutinemessig bruk av gP2S i laboratoriet og cryoEM-anlegget, kan ha en betydelig, positiv innvirkning på evnen til å straffeforfølge flere prosjekter parallelt over en periode på flere år. Etter hvert som flere og flere delte og sentraliserte kryoEM-grupper og fasiliteter etableres, forventer vi at behovet for informasjonsstyringssystemer som gP2S vil fortsette å vokse.
The authors have nothing to disclose.
Forfatterne takker alle de andre medlemmene av gP2S-utviklingsteamet som har jobbet med prosjektet 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 å ha hjulpet til med å sette sammen teamet og forme prosjektet.