Planned feature
This feature is not available yet. Here is what is planned, so you can tell whether it will cover your need — and tell us if it will not.
Status — in development
Planned availability — browser and server
In short
A project’s pipeline draws the chain running from the warehouse to your results: a database, a cohort, scripts, a dataset, a dashboard. Today it is a diagram — it documents your approach, it does not run it. Orchestration is under construction.
This page does not execute yet
A banner says so in the application: “This pipeline view is currently for visualization purposes only. Orchestration and execution features are under development.”
What you draw is saved, but no button runs anything. To actually produce a dataset, go through the IDE or import a file.
What the pipeline does today
It is a diagram editor. You place nodes on a canvas, you connect them, and the whole thing saves itself.
Its value is documentary, and that is not nothing: a research project spanning two years always ends up with steps nobody can reconstruct any more. An up-to-date diagram answers “where did this dataset come from?” without digging through history.
The six node types
| Node | What it represents |
|---|---|
| Database | A database linked to the project, picked from a list. The chain’s starting point. |
| Cohort | One of the project’s cohorts, picked from a list. Represents the filtering step. |
| Scripts | An ordered list of file paths — the transformation. |
| Dataset | The expected result, named by whatever you type. |
| Dashboard | End of chain. Linking to a real dashboard is not active yet. |
| Group | A frame for grouping nodes visually. Nodes dropped inside it move with it. |
You drag a component from the left panel, connect nodes by pulling from one handle to another, and the right-hand panel configures the selected node. Everything saves automatically — there is no save button.
Database and Cohort nodes point at real objects
Picking a database or a cohort in the panel genuinely attaches it to the node, and the node takes its name. Scripts and Dataset nodes, by contrast, expect free text: a file path, a name. Nothing checks that the file exists.
Two pipelines not to confuse
Linkr has two features by that name, and they do not operate in the same place.
ETL pipeline — warehouse
Database → database. Works.
Fills one database from another: this is where a source model is converted to OMOP. It genuinely runs. See ETL pipelines.
Project pipeline — this page
Warehouse → datasets. Diagram only.
Describes how a project exploits the warehouse: filtering, transformation, analysis.
The first builds the warehouse, the second exploits it. If you are trying to convert data into OMOP, the ETL pipeline is the one you want.
What is planned
The intention is for this diagram to become executable: one button, and the whole chain runs end to end.
The chain, from database to dashboard
It starts from a database
The warehouse, in its long format.
A cohort is drawn from it
The criteria run and delimit the day’s population.
The scripts run in order
Computing scores, aggregating, cleaning — in R, Python or SQL.
A dataset comes out
In wide format: one row per patient or per stay, one column per variable.
The dashboard displays it
It reads that dataset: once it is refreshed, so are the charts.
What this changes: a dashboard that keeps itself current
The clearest example is running a clinical unit. A dashboard shows the week’s activity, bed occupancy, lengths of stay. Today, keeping it current means someone re-runs the scripts by hand, re-imports the result, and checks nothing was missed — every day.
With an executable pipeline, the same thing fits in one sentence: the pipeline runs each morning, the cohort is recomputed on yesterday’s data, the scripts produce the dataset, and the dashboard shows current figures by the time the team arrives.
That is what separates a one-off analysis from a monitoring tool: not the quality of the charts, but the fact that nobody has to refresh them.
And the rest of the time
The data model already anticipates execution: every node carries a status — idle, running, succeeded, failed, stale — along with a row and column count. The interface displays these fields, but nothing fills them yet.
The guiding idea is a chain where each step produces a new output without overwriting its input: you re-run one step without recomputing everything, and you always know where each table came from. A stale status would then flag that an upstream step has changed since — so the displayed result no longer matches what produced it.
The pipeline is not included in a project export
While execution does not exist, the pipeline’s contents are excluded from export and versioning: they would produce differences nobody could act on. Your diagram therefore stays local to your installation — it does not follow the project to a git repository or to a colleague.
The Summary page's 'Datasets' counter reads this diagram
It counts nodes of type dataset drawn here, not the contents of Lab › Datasets. A gap between the two is therefore expected until the pipeline is finished.
In the meantime
Every step this diagram describes exists, separately and fully working:
- Cohorts — filtering patients, with real execution and attrition.
- IDE — writing and running transformation scripts.
- Datasets — the tables produced, genuinely stored.
- ETL pipelines — the other pipeline, the one that runs.