In short
A project is Linkr’s unit of work: a research question, the data it draws on, and everything produced from it. Its navigation reads in two halves — the data warehouse, where you explore what exists, and the lab, where you build. The Summary page gives you its state at a glance.
What a project gathers
A project answers a question: which ICU patients developed sepsis in 2023, and what predicts their outcome? Around that question it brings together the databases queried, the cohorts defined, the datasets extracted, the analysis code and the dashboards.
The point of that grouping is that it travels. A project exports, versions into a git repository and publishes — with its readme, its license and its authors. What moves between teams is not an isolated file but the whole approach.
A project does not own its databases
Databases belong to the workspace; a project links to them. Several projects can therefore work on the same database without duplicating it, and without one risking changes that affect another. See Databases.
Warehouse and lab
This is Linkr’s structuring distinction, and it reads straight off the sidebar: two groups, two colours, two logics.
Data warehouse
You explore what exists, read-only.
Databases, concepts, cohorts, patient data. Source data is never modified: you look, you count, you delimit a population.
Lab
You build from what you explored.
Datasets, dashboards, reports — and the IDE for code. This is where results live, and the only place your own output is written.
The separation is not cosmetic. It guarantees that an analysis, however clumsy, cannot damage the ward’s data: everything you produce lives beside the source, never inside it.
The data format changes between the two
The warehouse stores data in long format — one row per measurement, OMOP’s shape. Analyses generally expect wide format — one row per unit of analysis (a patient, a stay…), one column per variable. Moving from one to the other is explained in Organizing your data.
A project’s navigation
In sidebar order:
| Entry | What it is for |
|---|---|
| Summary | The project’s state, its readme, its license and its tasks. This is the landing page. |
| IDE | Write and run R or Python against the project’s datasets. |
| Pipeline | Sketch how the project’s steps chain together. Under construction — see Pipeline. |
| Data Warehouse | |
| Databases | The databases linked to the project, their statistics and their schema. |
| Concepts | What the database holds, concept by concept, with counts. |
| Cohorts | Delimiting a patient population. |
| Patient data | A single patient’s record, to check against the source. |
| Lab | |
| Datasets | The tables ready for analysis. |
| Dashboards | Visualizing and exploring a dataset. |
| Reports | Writing a document from your results. Under construction. |
| Versioning & export | Saving the project to a git repository, or exporting it as an archive. |
| Settings | At the bottom of the bar: members, permissions, and deleting the project. |
Both groups are open by default. When the sidebar is collapsed to icons, they open as a dropdown to the side rather than expanding in place.
The Summary page
This is a project’s landing page. Its header carries the name, the status (Active, Completed, Archived, Draft), the badges and the description.
It has four tabs: Overview, Readme, License and Tasks.
Overview
Four clickable counters — databases, cohorts, datasets, dashboards — then two columns mirroring the warehouse and the lab, each showing the two most recently updated items and a View link to the full list.
Above them, a preview of the readme and the To do list, whose boxes can be ticked straight from this page.
Readme, License and Tasks
The readme is written in markdown, with a preview and the option of adding attachments — an image embedded in the text, a protocol as a PDF. It is the first thing anyone receiving your project will read.
The license determines what others may do with your work. The copyright holder is inherited from the project’s organization, falling back to the workspace’s.
Tasks is a checklist, reorderable by drag and drop, alongside a free-form Notes area. Enough to keep track of a project running over months without leaving Linkr.
Creating a project
The New project button asks for little: a name, an identifier, and an optional description. The Metadata tab adds status, badges and a version number.
The identifier is permanent
It serves as the folder name in exports and in git: changing it would break the link with history already published. It is generated automatically from the name — 2 to 50 characters, lowercase letters, digits and hyphens — and locks on creation. The project’s name, by contrast, stays editable at will.
Settings and permissions
The Settings page manages the project’s members and their roles. Each major feature — cohorts, datasets, dashboards, versioning — has its own read, write and delete permission, which makes it possible to open up dashboard viewing without handing over control of the data.
Two tabs do not always appear: Folders, which requires server mode, and Delete project, reserved for owners.
Going further
- Entities and sharing — why everything in Linkr exports and publishes the same way.
- Cohorts — the first concrete step in most projects.
- Datasets — what analyses and dashboards work on.
- Versioning and export — getting the project off your machine.