gP2S is een webapplicatie voor het volgen van cryoEM experimenten. De belangrijkste functies worden beschreven, net als de stappen die nodig zijn om de toepassing te installeren en te configureren. Eenmaal geconfigureerd, stelt de applicatie het mogelijk om metadata in verband met negatieve vlekken en cryoEM-experimenten nauwkeurig vast te leggen.
Cryogene elektronenmicroscopie (cryoEM) is een integraal onderdeel geworden van veel geneesmiddelenontdekkingsprojecten omdat kristallografie van het eiwitdoel niet altijd haalbaar is en cryoEM een alternatief middel biedt om het ontwerp van ligand op basis van structuur te ondersteunen. Bij het behandelen van een groot aantal verschillende projecten, en binnen elk project een potentieel groot aantal ligand-eiwit co-structuren, wordt nauwkeurige registratie snel een uitdaging. Veel experimentele parameters worden afgestemd op elk doel, inclusief bij de monstervoorbereiding, rastervoorbereiding en microscopiefasen. Daarom kan nauwkeurige registratie van cruciaal belang zijn om reproduceerbaarheid op lange termijn mogelijk te maken en efficiënt teamwork te vergemakkelijken, vooral wanneer stappen van de cryoEM-workflow door verschillende operators worden uitgevoerd. Om deze uitdaging aan te gaan, ontwikkelden we een webgebaseerd informatiebeheersysteem voor cryoEM, genaamd gP2S.
De applicatie houdt elk experiment bij, van monster tot definitief atoommodel, in het kader van projecten, waarvan een lijst in de toepassing wordt bijgehouden, of extern in een afzonderlijk systeem. Door de gebruiker gedefinieerde gecontroleerde woordenschat van verbruiksartikelen, apparatuur, protocollen en software helpen elke stap van de cryoEM-workflow op een gestructureerde manier te beschrijven. gP2S is breed configureerbaar en kan, afhankelijk van de behoeften van het team, bestaan als een op zichzelf staand product of deel uitmaken van een breder ecosysteem van wetenschappelijke toepassingen, integreren via REST API’s met projectmanagementtools, applicaties die de productie van eiwitten of van kleine moleculen liganden volgen, of toepassingen die gegevensverzameling en -opslag automatiseren. Gebruikers kunnen details van elke raster- en microscopiesessie registreren, inclusief belangrijke experimentele metagegevens en parameterwaarden, en de afstamming van elk experimenteel artefact (monster, raster, microscopiesessie, kaart, enz.) wordt geregistreerd. gP2S dient als een cryoEM experimentele workflow organizer die nauwkeurige registratie voor teams mogelijk maakt en beschikbaar is onder een open-source licentie.
Informatiemanagement bij cryoEM-faciliteiten
Vanaf ongeveer 2014 is het aantal cryogene elektronenmicroscopie (cryoEM)1-faciliteiten explosief gegroeid, met ten minste 300 high-end systemen over de hele wereld2, waaronder bij een aantal farmaceutische bedrijven, wat een groeiende rol voor cryoEM weerspiegelt in medicijnontdekking3. De missies van deze faciliteiten en hun vereisten voor gegevenstracering en -beheer verschillen4. Sommige, bijvoorbeeld nationale cryoEM-centra, zijn belast met het ontvangen van EM-rasters, het verzamelen van datasets en het retourneren van gegevens aan de gebruikers voor structuurbepaling, misschien na wat geautomatiseerde beeldverwerking. In dergelijke faciliteiten is het volgen van de herkomst van het net, de associatie met een gebruikersvoorstel of subsidie en de afstamming van raster naar dataset cruciaal, maar andere factoren, zoals de methode voor zuivering van het eiwitmonster of het uiteindelijke structuurbepalingsproces, zijn minder of helemaal niet relevant. In andere faciliteiten, zoals lokale academische faciliteiten, is elke eindgebruiker verantwoordelijk voor het voorbereiden van zijn eigen monsters en rasters, het uitvoeren van de microscopie, het beheren van de ruwe gegevens en de verwerking en publicatie van de resultaten. Er is geen strikte behoefte aan het bijhouden van metagegevens van een dergelijke faciliteit, omdat deze rol wordt vervuld door de eindgebruiker of hun hoofdonderzoeker.
In onze cryoEM-faciliteit wordt de verwerking en optimalisatie van monsters, rasters, protocollen voor het verzamelen en verwerken van gegevens en resultaten (kaarten, modellen) in veel projecten gecentraliseerd op een kleine groep behandelaars. Dit brengt uitdagingen met zich mee in experimenteel (meta)datamanagement. De experimentele afstamming van structuren, van atoommodel tot de exacte identiteit van eiwitten en liganden, via rastervoorbereidingsparameters en protocollen voor gegevensverzameling, moet nauwkeurig worden vastgelegd en bewaard. Deze metagegevens moeten ter beschikking worden gesteld van een aantal menselijke actoren. Een persoon die bijvoorbeeld beeldverwerking doet, moet mogelijk weten welke constructie van een eiwit is gebruikt en wat de beeldvormingsparameters waren, ook al hebben ze het eiwit niet gezuiverd of de cryoEM-gegevens zelf verzameld; informaticasystemen zoals geautomatiseerde datamanagement-daemons moeten het project identificeren waarvoor een microscoop momenteel gegevens verzamelt om directorynamen correct en systematisch toe te wijzen.
Er zijn verschillende informatiemanagementsystemen beschikbaar om cryoEM-faciliteiten te ondersteunen. Misschien wel het meest complete onder hen is EMEN25, dat functies van een elektronisch lab notebook, een informatie management systeem en enkele elementen van een business process management tool combineert. Gebruikt bij vele synchrotrons, ISPyB6,oorspronkelijk gebouwd om de x-ray beamlines voor kristallografie te ondersteunen, ondersteunt nu ook cryoEM-gegevensverzameling. Scipion7 is een rijke en krachtige wrapper rond beeldverwerkingspakketten, waarmee gebruikers beeldverwerkingsworkflows kunnen opnemen en delen, bijvoorbeeld via de openbare repository EMPIAR8,9, en is ook geïntegreerd met ISPyB om on-the-fly cryoEM-gegevensverwerking mogelijk te maken.
Hier beschrijven we gP2S (voor Genentech Protein to Structure), een modern en lichtgewicht cryoEM informatiebeheersysteem dat is gebouwd om de workflow te ondersteunen van gezuiverd eiwit en kleine molecuul ligand tot het uiteindelijke atoommodel.
Overzicht van gP2S
gP2S is een gebruiksvriendelijk webgebaseerd cryoEM-informatiebeheersysteem dat nauwkeurige registratie voor cryoEM-laboratoria en multi-user, multi-project faciliteiten mogelijk maakt. De volgende entiteiten, hun relaties en bijbehorende metagegevens worden bijgehouden: projecten, apparatuur, verbruiksartikelen, protocollen, monsters, rasters, microscopiesessies, beeldverwerkingssessies, kaarten en atoommodellen. Gebruikers kunnen ook opmerkingen in vrije tekst toevoegen, optioneel inclusief bestandsbijlagen, waardoor een uitgebreide annotatie mogelijk is van elke entiteit die is geregistreerd in gP2S. De front-end is ontworpen om het gebruik met touchscreen-apparaten te vergemakkelijken en uitgebreid getest op 12,9″ iPad Pros, waardoor het mogelijk is om gP2S op de laboratoriumbank te gebruiken tijdens het voorbereiden van monsters en rasters(figuur 1),evenals op de computer bij het bedienen van de microscoop, het verwerken van afbeeldingen of het deponeren van modellen. Elke pagina in de front-end is bedoeld om handmatige gegevensinvoer te verminderen door parameters waar mogelijk vooraf in te stellen op verstandige standaardwaarden.
De backend van gP2S beschikt over een aantal REST API (REpresentational State Transfer Application Programming Interface) eindpunten, waardoor het mogelijk is om gP2S te integreren in bestaande workflows en scripts. Het gegevensmodel is ontworpen om het nauwkeurig vastleggen van negatieve vlekken en cryoEM-workflows mogelijk te maken, inclusief vertakking, bijvoorbeeld met één monster dat op verschillende rasters wordt gebruikt, gegevens van verschillende microscopiesessies die worden samengevoegd tot één gegevensverwerkingssessie of één gegevensverwerkingssessie die meerdere kaarten oplevert.
Systeemarchitectuur
gP2S is een klassieke drielaagse toepassing (figuur 2). In deze modulaire architectuur is het systeem verdeeld in drie afzonderlijke lagen, elk verantwoordelijk voor het uitvoeren van verschillende taken, en elk vervangbaar of aanpasbaar onafhankelijk van de andere. (1) De presentatielaag (of frontend) biedt gebruikers toegang via de webbrowser (uitgebreid getest met Chrome en Safari), maakt het mogelijk om workflowelementen (inclusief gegevensvalidatie) te maken en te wijzigen en geeft experimentele gegevens weer als afzonderlijke entiteiten, projectgebaseerde lijsten en volledige workflowrapporten. (2) De servicelaag (of backend) dient als tussenlaag tussen de gebruikersinterface en het opslagsysteem – het bevat kernbedrijfslogica, onthult de service-API die door de frontend wordt gebruikt, integreert met gegevensopslag en LDAP -systeem (Lightweight Directory Access Protocol) voor gebruikersverificatie en biedt een basis voor extra integratie met externe systemen. (3) De persistentielaag (gegevenstoegang) is verantwoordelijk voor de opslag van experimentele gegevens, gebruikersopmerkingen en bestandsbijlagen.
Sleuteltechnologieën en -kaders
Om de ontwikkeling, bouw en het onderhoud van de gP2S-toepassing te vergemakkelijken, werden verschillende technologieën en kaders in het project gebruikt. De belangrijkste zijn: Vue.js 2.4.210 voor de frontend en SpringBoot 1.311 met embedded Tomcat 8 server voor de backend. De toepassing maakt gebruik van MySQL 5.7- en MongoDB 4.0.6-databases voor opslag en LDAP12 voor verificatie. Standaard worden al deze onderdelen verzonden en geïmplementeerd als één toepassing.
In totaal gebruikt de applicatie honderden verschillende bibliotheken, direct of indirect. De meest prominente zijn opgenomen in tabel 1.
Gegevensmodel
In het gP2S-gegevensmodel kunnen drie typen entiteiten worden onderscheiden (figuur 3): werkstroomentiteiten met betrekking tot gegevens die tijdens experimenten zijn verzameld (bijvoorbeeld monsters of microscopiesessies); apparatuur en protocolentiteiten die gegevens beschrijven die in alle projecten gebruikelijk zijn (bijv. microscopen of vitrificatieprotocollen); andere entiteiten die ondersteunende of technische rollen in het systeem spelen (bijv. opmerkingen of standaardwaarden).
De hoofdmap van de werkstroomgegevensstructuur is de entiteit Project. Elk project bestaat uit een aantal Eiwitten en/of Liganden die bouwstenen zijn voor het maken van Sample entiteiten. Elk voorbeeld kan worden gebruikt om meerdere rasters te maken die op hun beurt worden gebruikt in microscopiesessies (één raster per microscopiesessie). De laatste worden toegewezen aan verwerkingssessies die een of meer kaarten kunnen opleveren. De laatste entiteit in de structuur is het atoommodel, gemaakt met behulp van een of meer kaarten. Bijgevolg is elke workflow-gerelateerde entiteit, van Eiwit tot Model, altijd gebonden aan een bepaald Project via zijn voorouders. Een dergelijk ontwerp creëert gegevensaggregaten die eenvoudig te verwerken zijn door de frontend-module of door externe systemen met behulp van de API.
Naast werkstroomgegevens zijn er entiteiten die apparatuur beschrijven die wordt gebruikt in experimenten of protocollen die zijn gevolgd tijdens het voorbereiden van rasters. Het definiëren van deze entiteiten is een vereiste voor het maken van experimentele werkstroomentiteiten zoals rasters, microscopie en verwerkingssessies.
Het laatste type gegevensentiteit, gezamenlijk “Overige” genoemd, wordt gebruikt voor technische doeleinden (bijv. bestandsbijlagen of standaardwaarden). Deze categorie bevat commentaarentiteiten die kunnen worden gekoppeld aan alle werkstroom- of apparatuur-/protocolentiteiten.
Beschikbaarheid van software
De open-source versie van gP2S is beschikbaar onder een Apache License Version 2.026, vanaf https://github.com/arohou/gP2S. Een Docker-installatie kopie voor gP2S is beschikbaar vanaf https://hub.docker.com/r/arohou/gp2s. Bij Roche & Genentech is een closed-source tak van gP2S in ontwikkeling.
De gP2S-toepassing uitvoeren
Er zijn twee manieren om gP2S uit te voeren: als docker container of als een standalone Java applicatie. De optimale keuze is afhankelijk van de doelimplementatieomgeving. Als bijvoorbeeld de mogelijkheid gewenst is om de code aan te passen of te verbeteren om aan specifieke behoeften van de gebruikers te voldoen, moet de hele toepassing eerst opnieuw worden gebouwd. In dit geval kan het uitvoeren van gP2S als een zelfstandige toepassing worden aanbevolen.
Docker container
De eenvoudigste manier om met de gP2S-toepassing te werken, is door deze uit te voeren als een Docker-service. Daartoe is een speciale Docker-afbeelding voorbereid en gepubliceerd in de Docker Hub-opslagplaats (“https://hub.docker.com/r/arohou/gp2s”). Het uitvoeren van de gP2S-installatiekopie is afhankelijk van de toegang tot MySQL- en MongoDB-databases en tot een LDAP-server. Voor niet-productieomgevingen wordt aanbevolen om al deze afhankelijkheden uit te voeren als Docker-toepassingen met meerdere containers, samen met de gP2S-toepassing. Om dit naadloos te maken, is een docker-compose bestand (https://github.com/arohou/gP2S/blob/master/docker-compose.yml) dat alle benodigde configuraties van de uiteindelijke omgeving bevat, voorbereid en geleverd in de gP2S GitHub-opslagplaats (https://github.com/arohou/gP2S). De volgende docker-afbeeldingen zijn afhankelijkheden: mysql27, mongodb28, apacheds29.
In de standaardconfiguratie worden alle opgeslagen gegevens, zowel entiteiten als bestandsbijlagen verwijderd bij het verwijderen van de docker-containers. Om de gegevens te behouden, moeten docker-volumes worden gebruikt of moet de gP2S-toepassing worden verbonden met speciale database-exemplaren (MySQL en MongoDB). De ApacheDS LDAP-servercontainer wordt geleverd met een vooraf geconfigureerde beheerder (wachtwoord: geheim). Deze referenties moeten worden gebruikt om u aan te melden bij de gP2S-toepassing wanneer deze wordt uitgevoerd als een Docker-service. Voor productieomgevingen kan hetzelfde docker-compose-bestand worden gebruikt om gP2S (en indien nodig andere containers) te implementeren als services voor een Docker Swarm-containerorkestratieplatform.
Het volledige proces van het uitvoeren van gP2S als een Docker-container, inclusief alle details met betrekking tot de juiste configuratie, wordt beschreven in de gP2S GitHub-opslagplaats en behandelt de volgende onderwerpen:
• Het uitvoeren van de dockerized gP2S-toepassing met alle afhankelijkheden.
• Toegang tot de gP2S-applicatie, database en LDAP.
• GP2S-service bijwerken met een nieuwe versie.
• Verwijderen van gP2S applicatie.
• Gegevens persistentie configureren.
• De dockerized gP2S-toepassing verbinden met speciale databases of een LDAP-server.
• Configuratiedetails
Zelfstandige Java-applicatie
Een andere optie om de gP2S-applicatie uit te voeren, is door een zelfstandig Java-pakket te bouwen. Deze aanpak moet worden gevolgd als het uitvoeren van Docker-containers niet mogelijk is. Voor het bouwen van de gP2S-toepassing moet een Java Development Kit versie 8 of hoger worden geïnstalleerd. Het hele buildproces wordt beheerd door de Maven-tool, die wordt geleverd in de codebase in github-opslagplaats. Build-configuratie is voorbereid om eerst het frontend-onderdeel te bouwen, vervolgens naar back-endbronnen te kopiëren en vervolgens te bouwen als een laatste toepassing. Op deze manier is het niet nodig om andere tools of bibliotheken te installeren om een volledig functionerend gP2S-pakket voor te bereiden. Standaard is het resultaat van de build een JAR-pakket (lokaal opgeslagen) en Docker-installatiekopie (gepusht naar de opslagplaats die is geconfigureerd in het maven pom.xml-bestand). Het is belangrijk om te onthouden dat informatie die nodig is om verbinding te maken met externe systemen (databases en LDAP-server) moet worden verstrekt in een goed configuratiebestand voordat het pakket wordt gebouwd.
Zodra het gP2S JAR-pakket is gemaakt, bevat het alle afhankelijkheden en configuratie-informatie die nodig is om de toepassing uit te voeren, inclusief de Tomcat-toepassingsserver die het systeem host. Als het pakket is gebouwd met meerdere configuratiebestanden, kan het in verschillende modi worden uitgevoerd zonder opnieuw op te bouwen.
De gP2S GitHub repository bevat een volledige beschrijving van het proces van het bouwen en uitvoeren van gP2S als een zelfstandige toepassing en behandelt de volgende onderwerpen:
• GP2S bouwen met behulp van de Maven-tool
• Bouwen en draaien met embedded databases
• Bouwen en uitvoeren met afhankelijkheden die zijn geïmplementeerd als docker containers
• Bouwen en draaien met speciale databases
• Authenticatie configureren
Bij correct en consistent gebruik helpt gP2S bij het goed bijhouden van hoogwaardige metadata door het registreren van kritische experimentele metadata af te dwingen met behulp van gestructureerde datamodellen en gedefinieerde vocabulaires, maar de toegevoegde waarde hiervan wordt pas volledig gerealiseerd wanneer een hoog niveau van compliance in het lab wordt bereikt. Het bovenstaande protocol heeft geen betrekking op hoe dit te bereiken. We stelden vast dat een effectieve handhavingstechniek was dat microscoopexploitanten weigerden gegevens te verzamelen over netten die niet in gP2S waren geregistreerd. Dit dreef de naleving zeer snel op en legde de basis voor de opkomst, in de daaropvolgende maanden, van een grote hoeveelheid gedetailleerde en nauwkeurige experimentele details en bedrijfsgeheugen. Na een paar maanden gebruik werd de waarde van het corpus van metadata opgeslagen in gP2S voor de meeste gebruikers zo duidelijk dat de naleving hoog bleef zonder expliciete tussenkomst.
Om dit collectieve geheugen volledig te benutten, moeten de in gP2S opgeslagen metagegevens toegankelijk zijn voor externe systemen en gemakkelijk worden gekoppeld aan de experimentele gegevens (micrografen) en resultaten (kaarten en modellen). Het bovenstaande protocol beschrijft niet hoe gP2S kan worden geïntegreerd met andere informatica- en gegevensverwerkingssystemen. Het meest eenvoudig zijn potentiële integraties via de back-end REST API van gP2S, waarvoor geen wijziging van gP2S nodig is. Elke computer die onze gegevensverzamelingsdetectoren beheert, voert bijvoorbeeld een script uit dat periodiek het eindpunt van gP2S “getItemByMicroscope” onder de REST-controller voor microscopiesessies opvraagt om te controleren of er een microscopiesessie aan de gang is op de microscoop. Als dat het geval is, haalt het script van gP2S de juiste mapnaam voor gegevensopslag op (zoals geconfigureerd op de pagina Instellingen, zie hierboven) en maakt het een map op het lokale gegevensopslagapparaat met deze naam. Dit zorgt voor een systematische naamgeving van gegevensopslagmappen en vermindert het risico op fouten als gevolg van typefouten.
Hoewel ze zijn opgemerkt in de bron van de openbare versie van gP2S, zijn verdere integraties met betrekking tot gP2S die de gegevens van externe systemen verbruiken ook mogelijk. In ons lab integreert onze implementatie van gP2S met (i) een projectmanagementsysteem, zodat elk project dat in gP2S is geconfigureerd, kan worden gekoppeld aan een bedrijfsbreed portfolioproject en metadata uit het portfolio binnen gP2S kan worden weergegeven; ii) een eiwitregistratiesysteem, zodat elk eiwit dat aan gP2S wordt toegevoegd, via een lokaal opgeslagen identificatiecode wordt gekoppeld aan een volledige reeks registers waarin de herkomst van het eiwit wordt beschreven, met details over de relevante moleculaire biologie, het expressiesysteem en de zuivering; iii) een klein molecuulverbindingsbeheersysteem, waarmee gP2S belangrijke informatie over elke ligand, zoals de chemische structuur ervan, kan weergeven. De codewijzigingen die nodig zijn om deze integraties mogelijk te maken, worden beschreven in de sectie ‘Integratie’ van het README-BUILD.md document dat beschikbaar is in de gP2S-opslagplaats (https://github.com/arohou/gP2S).
De huidige versie van gP2S heeft beperkingen, waaronder het overdreven simplistische gegevensmodel en frontend voor structuur (Model) depositie. Dit werd opzettelijk achtergelaten in een “barebones” staat in de vrijgegeven versie van gP2S omdat een volwaardige structuurdepositie- en validatiefunctie momenteel in ontwikkeling is, samen met ondersteuning voor röntgenkristallografie. Een andere ontwerpbeslissing was om geen privilege- of machtigingssysteem te implementeren: alle gebruikers in gP2S hebben gelijke toegang tot de functies en gegevens. Dit kan het een slechte keuze maken voor faciliteiten die gebruikersgroepen bedienen met concurrerende belangen en vertrouwelijkheidsvereisten, maar was geen zorg voor onze faciliteit.
De ontwikkeling van onze interne versie van gP2S is aan de gang en het is onze hoop dat de hier beschreven open-sourceversie nuttig zal zijn voor andere cryoEM-groepen en dat sommige in de toekomst suggesties of codeverbeteringen kunnen bijdragen. Toekomstige waardevolle ontwikkelingen zouden zich bijvoorbeeld kunnen richten op integraties met laboratoriumapparatuur (vitrificatierobots, elektronenmicroscopen), software (bijvoorbeeld om metadata voor beeldverwerking te oogsten) en externe openbare repositories (bijvoorbeeld om structuurdeposities te vergemakkelijken).
De systematische verzameling van hoogwaardige metadata die mogelijk wordt gemaakt door routinematig gebruik van gP2S in het lab en de cryoEM-faciliteit kan een aanzienlijke, positieve impact hebben op het vermogen om meerdere projecten parallel over een periode van jaren te vervolgen. Naarmate er steeds meer gedeelde en gecentraliseerde cryoEM-groepen en -faciliteiten worden opgericht, verwachten we dat de behoefte aan informatiemanagementsystemen zoals gP2S zal blijven groeien.
The authors have nothing to disclose.
De auteurs bedanken alle andere leden van het gP2S-ontwikkelingsteam die sinds de oprichting aan het project hebben gewerkt: 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 Surdack. We danken ook Raymond Ha en Claudio Ciferri voor hun hulp bij het samenstellen van het team en het vormgeven van het project.