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. The Plugins page files them under two tabs, Data Warehouse and Lab, and a new plugin takes the family of the open tab.
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 code is part of the application: you can read them, not change them — their card has no ⋯ menu.
Plugins
Create and manage analysis plugins.
Descriptive table of a population
Survival curve and log-rank test
SOFA computed per day of stay
An indicator tracked over time
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 one of your plugins
The usual route: start from an analysis that works and adapt it. The original stays untouched. Built-in plugins cannot be duplicated.
Create a blank plugin
For an analysis unlike any other. You write the code and declare the settings it exposes.
Import a plugin
Pick up another team’s plugin from the ZIP archive they exported: the page’s Import button. See Import and export.
The editor
A plugin is a set of files — its plugin.json manifest, the analysis code template, its documentation. The editor’s Code tab lists them on the left, opens the chosen file in the middle, and adds on the right an output pane with three tabs 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.
- Code — the code as it will run, once the settings are substituted into the template.
- Results — the plugin’s output on real data. Test configuration, in the toolbar, picks the project and dataset (or, for a warehouse plugin, the database and patient) and the language; Run starts the test. 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. The dashboard says so — “2 widgets use a plugin version that has changed since they were created” — with Accept new version for each; it is worth knowing before publishing a fix.
Sharing a plugin
A plugin is an entity like any other: it carries an author and a licence, exports as a ZIP archive and versions to a git repository, from its card’s ⋯ menu. It also travels in its workspace’s export. See Entities and sharing.
No plugins in the catalog yet
The community catalog does not list plugins for now: you can neither install nor publish a plugin there. To hand one over, send its ZIP archive, or share the workspace that holds it.
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 — the author, licence and version to fill in before handing a plugin over.