Linkr
Home Resources Tools Documentation Blog Demo
FR
  • What is Linkr?
  • Deployment modes
  • Quickstart
  • Local install
  • Your first project
  • Workspaces and projects
  • The data pipeline
  • Versioning and collaboration
  • Schemas WIP
  • Databases WIP
  • Data quality WIP
  • ETL pipelines WIP
  • Concept mapping
  • Introduction
  • Mapping projects
  • Overview
  • Target Concepts
  • Mapping Editor
  • Suggestions
  • Evaluation
  • Export
  • Data catalog WIP
  • Cohorts WIP
  • Patient-level data WIP
  • Datasets WIP
  • Script collections WIP
  • IDE WIP
  • Dashboards
  • Reports WIP
  • Build a plugin WIP
  • Overview
  • Tabs and widgets
  • Built-in widgets
  • R, Python and SQL code
  • Filters, settings and export
  • Wiki WIP
  • Versioning WIP
  • Production install WIP
  • Authentication and permissions WIP
  • Configuration WIP
  • Backup and restore WIP
  • Glossary WIP
  • Release notes WIP
Documentation Core concepts Workspaces and projects

Workspaces and projects

Linkr's two organisational levels: the workspace, a shared container, and the project, the unit of work.

Summary

Linkr is organised into two nested levels. The workspace is a shared container — at the scale of a department, a hospital or a network — that gathers projects, common resources (databases, schemas, wiki, plugins) and a git configuration. The project is the concrete unit of work: a study, a monitoring board, a dashboard, with its data, cohorts, analyses and code.

Client Available in client-only mode — runs entirely in the browser, no backend. Backend Backend (FastAPI) under development.

Two levels of organisation

When you open Linkr, you always move through a two-level hierarchy: you first pick a workspace, then a project inside it. Above them, an organisation (your hospital, university or consortium) acts as a signature: it identifies who produces and publishes the work.

The context

Organisation

The institution behind the work (hospital, university, consortium). An attribution metadata, not a container.

The container

Workspace

Gathers projects and shared resources: databases, schemas, wiki, plugins, git.

The unit of work

Project

A study, a monitoring board, a dashboard — with its data, cohorts, analyses and code.

A workspace contains several projects; a project belongs to a single workspace.

Workspace

Project — Sepsis study

Project — ICU monitoring

Project — COPD cohort

The workspace

A workspace is a shared container. You create one for a collaborative perimeter: most often the team running a health data warehouse or a research network, but just as well a department, a hospital or any other working group. Every member of a workspace sees and reuses the same resources.

A workspace gathers:

Projects

Studies, monitoring boards, dashboards. This is the main content.

Warehouse connections and schemas

The connections to the available warehouses and how to interpret them (OMOP, MIMIC, custom presets), shared across projects.

Cross-cutting resources

Concept mapping, data quality, ETL pipelines, SQL script collections, data catalog — pooled at the workspace scale.

A wiki and plugins

Team documentation and reusable analysis plugins, available in every project of the workspace.

In client-only mode (browser only), you work in a single implicit workspace. The ability to create and switch between several workspaces, with distinct members and permissions, belongs to the full-stack mode, under development (see Deployment modes).

A typical setup

A hospital keeps a private workspace (ongoing research, internal dashboards, connected to a private GitLab) and a public workspace (published studies, shared methods, connected to a public repository).

The project

The project is the unit of work. This is where you spend most of your time: exploring data, building a cohort, producing a dataset, composing a dashboard, writing code. A project belongs to a single workspace.

A project brings together everything that contributes to a study or a monitoring board:

  • The project warehouse — the active databases, concepts, cohorts, data quality.
  • The pipeline — the transformations that prepare data for analysis.
  • The lab — the analytical datasets, analyses and dashboards.
  • The IDE — an integrated Python / R / SQL environment for custom code.
  • Versioning — exporting and sharing the project.

How warehouse, pipeline and lab fit together

These three spaces form the core of a project and follow the path of the data, from raw records to results. That is the topic of the next page: The data pipeline.

A project = an IDE view = an archive = a git repository

A defining principle of Linkr: a project’s content is the same object whichever angle you look at it from. What you see in the IDE, what you get from a ZIP export, and what would be versioned in a git repository are one and the same file tree — JSON configuration files, your scripts, your data.

my-project/
├── project.json — project metadata
├── README.md
├── scripts/ — your code (the only editable folder in the IDE)
├── pipeline/ — the transformation graph
├── databases/ — databases and their schema mapping
├── cohorts/ — the defined cohorts
├── dashboards/ — the dashboards
└── datasets/ — the analytical datasets

This equivalence has a practical consequence: saving, sharing and versioning a project are the same gesture — handling this file tree. That is what makes ZIP export and git versioning feel natural in Linkr. See Versioning and collaboration.

Further reading

  • The data pipeline — how data flows through a project, from the warehouse to the dashboard.
  • Versioning and collaboration — sharing and versioning projects and workspaces.
  • Your first project — a guided end-to-end walkthrough.
PreviousYour first projectNextThe data pipeline

Product

  • Home
  • Demo

Resources

  • Documentation
  • Resources
  • Tools
  • Blog

Community

  • Framagit source code
  • Github source code

About

  • InterHop.org
  • Contact

2021–2026 InterHop — CC BY-NC-SA 4.0 (site) · GPLv3 (software)