Summary
A project's data warehouse gathers read-only clinical data and makes it explorable without writing a line of code. It has four screens: Databases (what is plugged in and what it holds), Concepts (the dictionary of measured variables), Cohorts (selecting a population from criteria) and Patient data (one patient's record, rebuilt as a board of widgets).
Every screenshot below comes from the ICU Mortality Prediction Example project, available in the public demo. The data is the MIMIC-IV Demo — 100 real intensive care stays, de-identified and published by MIT. Click any screenshot to enlarge it.
Databases
A project does not store data itself: it connects to one or more databases declared in the workspace. The Databases screen lists those feeding the project, with their connection status and licence.
Opening a database, the Statistics tab gives an immediate overview of its contents: patient count, gender split, number of hospitalizations and unit stays, mean and median durations, and the admission curve over time.
The Schema tab next to it describes the tables and their columns — useful for understanding how the database is laid out before writing a query.
Concepts
A concept is a measured variable: a respiratory rate, a drug, a diagnosis. The Concepts screen is the dictionary of everything the database holds — 5,636 concepts here — each with the number of patients involved and the number of records.
This is the screen that answers the questions asked before any analysis: is this variable measured in enough patients? Are its values plausible? The right-hand panel shows the histogram, mean, median and standard deviation, making an inconsistent unit or an outlier visible at a glance.
Cohorts
A cohort is a population defined by inclusion criteria. You build it without SQL, by stacking criteria combined with AND.
In the builder, each criterion is a card: an age (at admission or current), a sex, a vital status, and many more. The NOT toggle inverts a criterion — in the example below it is used to exclude deceased patients.
The result is computed on the fly. Two details are worth pointing out: the Attrition tab shows how many patients each criterion removes, and the SQL button reveals the generated query — handy to check the definition, or reuse it elsewhere. The cohort then becomes a reusable filter across the rest of the project.
Patient data
The three previous screens reason about populations. Patient data does the opposite: it rebuilds one patient's record. A project can hold several boards, each assembling its own widgets.
A board is organised into tabs. The demo one has five: Patient summary, Data overview, Notes, Haemodynamics and Ventilation. The right sidebar stays constant: it selects the cohort, then the patient, then the hospitalization to display.
The Data overview tab answers a question that is hard to address any other way: what was actually measured in this patient, and when? Each row is a concept, each point a measurement, all aligned on a shared timeline and grouped by category — vitals, labs, prescriptions, inputs, outputs, procedures.
The following tabs are thematic. Haemodynamics overlays circulatory vitals and, below them, the vasopressors administered — both share the same time axis, so a dose can be read against its effect.
Building your own widget
These tabs are not fixed: the Edit button opens edit mode, where you add tabs and widgets. The first step is choosing the concepts the widget displays, in the same table as the Concepts screen — with the same statistics at hand to check a choice before confirming it.
Then comes the widget's own configuration: its name, the renderer, and the display options — Y axis starting at zero, step plot, line thickness. The preview on the right updates live, using the selected patient's real data.
Going further
- The MIMIC-IV database — where this data comes from, what it contains and how to get real access to it.
- Quickstart in the browser — run through the same journey on your own data.
- Health data warehouses — the concept, its uses and its limits.