Oncodash — Developer Documentation
Oncodash is decision support system that help tumour boards to come to the best decision for their patients. Oncodash is currently developed within the DECIDER project and targets high-grade serous ovarian cancer.
Oncodash is an open-source software, see the Github project page.
This web site serves the developer documentation of Oncodash. For more information on the features and how to operate Oncodash, see the User Manual.
Features Overview
The main approach of Oncodash is to have a so-called "view" for each specialty in the tumour board. For phase I of the development, we plan to have two of them: the clinical view and the oncology view (see Figure C and Figure O).
Views are displaying data that come from several sources:
- patient clinical data (name, age, cohort, etc.),
- longitudinal clinical data (blood levels, dates of chemotherapies, etc.),
- samples (location, date, etc.),
- images (histopathology, etc.),
- omics data (altered gene found in a sample, mutation, etc.),
- inferred data (actionable drug for an alteration, potential side effects, etc.).
Try the application
The recommended way of building up the application is to make use of the provided Docker containers.
To build and run the application server, run the following commands:
docker-compose build
docker-compose run --rm backend sh -c "python manage.py makemigrations"
docker-compose run --rm backend sh -c "python manage.py migrate"
docker-compose up
Then point your favorite browser on http://localhost.
There is currently no official instance running online.
Architecture
REST
Oncodash is a modern Web application, that is operated on a Web server and reached through a Web browser. As such, it is first decoupled between the "frontend" (what runs on the operator's browser) and the "backend" (what runs on the server, see Figure R).
Oncodash is architectured around "REpresentational State Transfer" (REST), which is considered gold standard for developing application for the Word Wide Web. It exposes web services on URIs, serving data on request via HTTP, using JSON payloads. Most of the service modules are written in Python, and use the Django framework. Those data are then visualized within the browser, in a web application written in Typescript (a modern evolution of Javascript) and using the Web Components standard, as implement by the Lit library.
Layers
The graphical interface that an operator is seeing is a collection of views. Views are an interface displaying a set of information about patient(s), tailored for a medical specialty. It generally occupy a large portion of the screen.
Each view is an assembling of widgets, that are interactive graphical user interface objects, which can be used in several views. For instance, the timeline widget is both used in the clinical and oncology view. Each widget has an independent data source, which is an entry point in the backend API (see Figure L). Interactive widgets can also send data to the backend, modifying the internal state, and thus what is displayed by the other widgets.
The backend is mainly focused on managing states of the views. States are collections of data, which can be internal configuration of widgets or, most importantly, data about the managed patient(s). The backend is thus organized as a set of modules managing data (see Figure).
The main layers (i.e. types) of modules are:
- API: service functions that may take a (JSON) input from a client, and returns a (JSON) data structure.
- Querying: select a subset of data of interest.
- Conversion: convert data to/from a format from/to the JSON datastructure used in the APIs.
- Storage: store data permanently.