Summary
A plugin is a packaged analysis: you configure it instead of rewriting it, and it becomes a widget available in every project of the workspace. Linkr ships a library of them, marked Built-in, and you can build your own — from an existing plugin or from a blank page — in an editor that lets you test them on real data before handing them out.
Why package an analysis
A useful analysis is rarely useful only once. The same survival curve, the same descriptive table, the same control chart come back from one project to the next, give or take a few columns.
Without plugins, you copy code from one project into the next. And the day you fix a mistake, you fix it in one copy — the others keep producing wrong numbers.
A plugin moves the line: the analysis is written once, exposed with settings, and it is the settings that change from project to project. What gets fixed gets fixed for everyone.
Two families of plugins
A plugin declares where it is used, and that determines where in Linkr it shows up.
Lab
Analyses working on a dataset — one row per patient.
These are the most numerous: descriptive table, survival, regression, plots. They are shared between the Datasets page and dashboards: an analysis worked out on a dataset then drops in as a widget unchanged.
Warehouse
Views working on one patient’s individual data.
Measurement timeline, demographic summary, clinical notes. They appear in patient dashboards, where you look at one record at a time rather than a population.
The distinction comes down to the shape of the data. A lab plugin receives a table; a warehouse plugin receives one patient’s record. You pick the family at creation, and it determines where the plugin will be offered.
The plugins that ship with Linkr
Linkr comes with a library of ready-made analyses — descriptive table, survival, regression, control charts, plots, indicators, geographic map. They carry the Built-in badge and cover most common needs.
Their detailed catalogue is on the Built-in widgets page.
The easiest way in is to look at them. In the demo, the workspace’s Plugins page lists them all: open one to read its documentation and browse its settings.
Every plugin carries its documentation
A plugin embeds its own instructions, readable from the Doc tab when configuring a widget. That is where to find what an option actually does — more reliable than guessing from its name.
Building your own
Three starting points, from the simplest to the most open.
Duplicate an existing plugin
The usual route: start from an analysis that works and adapt it. The original stays untouched.
Create a blank plugin
For an analysis unlike any other. You write the code and declare the settings it exposes.
Install from the catalog
Pick up a plugin published by another team. See Community catalog.
The editor
A plugin is a set of files — the analysis code, its documentation, any resources it needs. The editor shows them side by side and adds two panels that make the difference.
- Config — a preview of the settings as the widget’s user will see them. It is how you check that an option makes sense without having read the code.
- Test — running the plugin on real data: pick a project, a dataset or a database, and see the result. Essential before putting an analysis in a team’s hands.
Editing a plugin affects existing widgets
Widgets already placed on dashboards use the plugin, they do not hold a copy of it. Changing the analysis therefore changes what they display. Linkr flags the affected widgets — but it is worth knowing before publishing a fix.
Sharing a plugin
A plugin is an entity like any other: it exports, versions to a git repository, and publishes to the catalog with its author and licence. See Entities and sharing.
That is what lets an analysis method travel between institutions in directly runnable form, rather than as a paper someone has to reimplement.
Going further
- Built-in widgets — the catalogue of shipped analyses.
- R and Python code — for a one-off analysis that does not warrant a plugin.
- Publishing content — sharing a plugin beyond your institution.