Features on the grit42 platform

General features

User admin

Embedded in the grit42 platform is user administration. This is where super users (or other users with the role to do so) can setup new users as well as give the users the roles they need in order to perform the tasks they need to on the platform.

The main difference between the users on the platform will be the ability to “write” vs only “read” in the different areas of the platform. As a default all users have read rights on all the data but only the relevant users have the ability to write – and hence add/change data.

Drag/Drop data upload

A standard feature across the platform is the ability to upload data by drag/drop of files into the front end. Doing so will take the user through a process for mapping the columns in the file to the relevant columns in the database. The system will try to do an automatch – so if the headers in the file match the headers of the columns in the database the system will perform the mapping and the user just need to review and click “Upload”.

All this is handled by our “upload piece” with data going into the database in a “pre-load” area where different QA/QC steps can be added before the data is loaded into the “real” data tables. Doing it this way enables us to keep track of the loaded files – and the data in them – and hence to be able to rollback and take the data out again if the users regret the upload for some reason or the other.

Results request

The grit42 platform also contain a “request a new result” feature where users can ask for test of certain compounds in certain versions of the registered setups (also called assays or models). The requests can be initiated from several different places in the platform – ie. from the compound and experiment. The requests can also be initiated directly from within a SAR table where users can point to the combination of compound/experiment and ask for a new or another results to be produced on that combination.   

Table and list features

Lists

Each user can create lists and store the lists in the database for later reuse. The lists can have different content dependent on the list type – so it could be a list of compounds or a list of experiments. Apart from being a collection and placeholder for your content of interest, the lists can also be used as input to searches, compound or results ordering, as well as the basis for creation of a SAR table.

Hence the following scenario could be supported by the lists.

  1. First you create a list of compounds and experiments of interest.
  2. Then you use the compound list as the basis for several results orders – an order per the experiments you would like results on.
  3. And finally you combine the compound list and the experiment list into an (empty) SAR table.

When the experiments are performed by the relevant scientists and the data is uploaded to the database, your SAR table will be populated with the corresponding results and you can start your analysis – and in turn decision making.

SAR tables

With a database containing both structures and compounds as well as the results from pharmacological in vitro and in vivo as well as ADME and safety tox experiments a natural feature request would be to combine the data across the database to enable decision making. One such cross-database analysis is a SAR table where the user can combine compounds (structures) in a table with the relevant results to compare the compound activities in a Structure-Activity-Relationship analysis. Each user of the grit42 platform has the ability to do so – and create as many as they like – and store these SAR tables for later use and review.

The SAR tables display one single result (number) per combination of compound/experiment. But often these numbers represent an average over several results as the same compounds are often tested in the same kind of experiment several times. The user can – by a simple click on the number – see the underlying results and the math that accounts for the displayed number and decide to change the math, bogus some results etc. These changed only takes account in the individual SAR table – it does not change anything in other users views of the same data.

Cool SAR features:

  • Request new results directly from the SAR table
  • See underlying data and be able to manipulate for own SAR table

Compound features

Structure/Compound registration – SD-load and singleton

Uploading structures and compound information to the grit42 platform can be done in different ways. Bulk upload of many structures – either as a one-off to populate the database or a collection of ie. last week’s new compounds – can be done by a simple drag/drop of an SD-file and subsequent mapping of the data in the file to columns in the database. This process utilises the general file upload functionality of the platform combined with structural awareness from RDKit. Structure quality checks as well as duplicate checks against the existing structures in the database is part of this process.

Alternatively, users can register new structures and compounds via the “singleton registration” form where structures are drawn and users add the relevant meta data. Hence, no matter how you wish to use the platform – general data management or support your daily workflows – there is a possibility to add all your relevant chemical and structural information.

When the platform is only being used for data storage or analysis purposes – for example as a data warehouse – the underlying complexity of what batches of the compounds were used in the individual experiments are sometimes forgotten/avoided. But as soon as day-to-day support of the experiment and data management becomes relevant the batch complexity needs to be taken into account. In these cases the structure/compound registration should be extended by registration of the individual batches of the compounds enabling linking of the experiment data to the relevant batch.

Structure searching – substructure, similarity etc

Chemical awareness is build in across the platform in the sense that filters in all the tables with relevant structural information has exact match and substructure searching available. These searches can be combined with meta data filters so users can look-up compounds with certain substructures and relevant chemical properties.

Global search and comparison features

Browse: “Find all data on this Compound”

The grit42 platform has another unique “search across the database” feature where the user can ask questions like “show me all the results on this compound”. These kind of questions can assist the users in the understanding of how the different compounds “behaves” by delivering an overall view despite the fact that the results are from very different types of experiments.

The search result is a list of the experiments the compounds has been involved in on the left hand side of the screen and by clicking the individual experiments the user will get a relevant view of the underlying data in the right hand side of the screen. Showing the data from in vitro plate based and in vivo group data together naturally does not make any sense – doing it our way delivers both the overview and the data without mixing apples and pears.

Standard “across the platform” functionality and look’n’feel on all grids

  • Meta data searching across 
  • Export data to excel and plots to png’s
Cross experiment comparison

Now and then – in order to get potential insights – scientists need to look across different experiments and compare the data. The comparisons can have different foci – a Quality Control of the experiment, to find the best candidate, or as a way to compare against a baseline or reference data point.

This is very often a rather tedious exercise where data from the different experiments need to be merged before any analysis can be initiated. As we keep the raw experimental data as well as the final results in the same platform, in the same format and with relevant metadata and role tags around them a comparison exercise in our platform is as simple as a search/select/load in order to combine an existing data set with the newly produced and have the data plotted together in the relevant visualisation.

Re-analysis of old raw data

The raw experimental data produced during an experiment should as default never be deleted again. It’s an experimental fact of life produced by someone, somewhere under specific circumstances. As a contrast the algorithm applied to the raw data as well as the resulting “final results” are not necessarily a static never-to-be-changed piece of data.

We therefore store the raw data separately – away from the algorithm and final results – to keep facts in one place and interpretations and conclusions in another place. This also enables easy re-analysis of the raw data later if/when new algorithms or visualisations appear. You just create a new experiment, re-use the unchanged raw data and apply new interpretations.

External analysis

API based access to the data

We aim at supporting all the analysis needed for the day-to-day lab work incl QC and interpretation of the results. But some of the more advanced cross-database bioinformatics type of analysis should be performed by relevant scientists. In order for them to do that we offer other ways of interacting with the data outside of the general grit42 front end.

One of these is a standard API type access whereby the users can utilise the REST calls we have exposed from the platform. The grit42 platform is build on a REST based web framework and hence the exposed API calls are a general nature of the grit42 platform – not an artificial afterthought – and what we use internally to develop front end.

Using the REST calls scientists can access the data in the platform from their preferred data analysis tools and programming languages like Python.