Overview

What a dashboard is for

Once your data is prepared and your cohorts are built, you want to surface them: describe a population, compare groups, track an indicator over time, share a result with a team. That is what dashboards are for.

In practice, a dashboard answers questions like:

• What is the mean age of my cohort, and how is it distributed?
• How many admissions per month, and how do they trend over the year?
• Does length of stay differ between two patient groups?

Rather than rewriting the same code every time, you compose a view from configurable widgets, replay it on new data, and share it.

A dashboard is also interactive: with filters, you narrow the view to a sub-population — a patient cohort, an age range, a time period — and every widget recomputes on the fly. So it is also a way to explore your data, drilling into a subgroup without going back to the code.

Two uses: research or monitoring

A dashboard serves two rather different ends with the same mechanics.

Research

A study usually spans two stages, and so often two separate dashboards. A first one is for exploring: you filter on a cohort, compare subgroups, check a hypothesis — all interactively, without rewriting code. A second one, once the analyses are settled, presents the conclusions, organised by theme: a Demographics tab, a Flowchart tab (the cohort flow diagram), a Predictive models tab… This is exactly the point of being able to create several dashboards within one project (see below). In both cases the view works on a snapshot of the study’s dataset.

Monitoring

Here you track activity with data refreshed at a regular interval (every 24 hours, say). You organise by monitoring axis — Demographics, Microbiology, Ventilation… — to follow patients as they go, like a ward dashboard.

In both cases the assembly is the same: tabs grouping widgets. The difference lies mostly in data freshness — a snapshot for research, a periodic refresh for monitoring — and in how you split the tabs.

Several dashboards per project

A project is not limited to a single dashboard. Create as many as you need to break up your work. This is exactly what lets you separate the two stages of a study mentioned above: an Exploration dashboard to drill into the cohort interactively, and a Results dashboard to present the settled conclusions. You can add others as needed — say one dedicated to Predictive models. Each has its own name, tabs, widgets and filters.

The same idea applies to a monitoring project: one dashboard for the ward’s general monitoring, another dedicated to a specific cohort (say traumatic brain injury patients), and so on. Study and monitoring do remain separate projects, though — you do not mix a study’s fixed results and a continuously refreshed monitoring view in the same project.

The structure: dashboard → tabs → widgets

A dashboard is organised on three levels:

The tab bar at the top is for navigation; the toolbar on the right gives access to filters, fullscreen, settings and image export. Below, the widgets sit on a grid where you move and resize them.

What this section covers

The following pages detail each building block:

1. Tabs and widgets — create and organise tabs, add widgets, position them on the grid.
2. Built-in widgets — the catalogue of ready-made analyses (Table 1, plots, survival, regression, Sankey, map, key indicators…).
3. R, Python and SQL code — write your own code in a widget to produce custom output.
4. Filters, settings and export — filter several widgets at once, tune the layout, go fullscreen, export images, version and deploy.