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 — under consideration
Planned availability — browser and server
In short
Carving a restricted working database out of the main warehouse: you select patients exactly as you would build a cohort, then Linkr projects every event table onto those patients. The result is a database you query like any other, which remembers where it came from and on what criteria — so it can be rebuilt.
The need
A hospital warehouse holds every patient. A study concerns only a fraction of them: one department, one period, one condition.
Today there are two imperfect answers. You work on the whole warehouse and filter in every query — each analysis then has to remember the filter, and one that forgets produces a wrong number. Or you ask the data team for an extract, and wait.
A derived sub-database aims at the middle ground: the perimeter is defined once, materialised, and everything that queries it is already in the right perimeter.
This is not the same thing as a cohort
A cohort is a list of patients. A sub-database is a complete database: the same tables as its parent, with the same column names, restricted to a subset of patients. You query a sub-database; you use a cohort as a filter. Where exactly the line falls between the two is part of what remains to be settled.
What is planned
Selecting the way you build a cohort
Half the work is already solved elsewhere in Linkr: the cohort criteria builder. Same criterion types, same tree, same levels — patient, hospitalization, unit stay, event.
The intent is to reuse that builder as it is, not to write a second one. Anyone who can build a cohort will be able to define a sub-database without learning anything new.
Then projecting every table
Once the patient set is fixed, Linkr walks every event table of the parent database and keeps only the rows belonging to those patients. The schema is identical: a query written for the parent works on the sub-database unchanged.
Two possible forms
A new database
The filtered tables are written to a separate database.
It appears in the database list with its own statistics and a schema inherited from its parent. Nothing is written into the warehouse: this is the route that works everywhere, including when the warehouse is read-only.
A schema inside the parent
The filtered tables live in the warehouse itself.
More economical — no second copy — but it assumes write access to the production warehouse, which many IT departments will refuse. Server mode only, and only on some engines.
Remembering what was carved out
A sub-database will record its parent database, the criteria tree that produced it, and the date it was built.
That is what answers, six months later, the question that always comes up: what exactly is in here? And because the criteria are kept, the sub-database can be rebuilt once the warehouse has been updated.
The definition — the criteria and the pointer to the parent, never the data — would travel with the workspace export, like everything else.
What is not settled
This page describes an idea, not a decision
Several structural choices are still open. They are listed as they stand: if one of them matters for your use, now is the time to say so.
- The name. “Datamart”, “sub-database”, “study base”, “extract”? The term will end up in the interface and in URLs, so it has to be chosen before the code is written — and it hasn’t been. This page says “derived sub-database” for want of anything better.
- The line with cohorts. A materialised cohort looks a lot like a sub-database. Should there be two features, or one with two outputs? The risk of duplication is real.
- What kind of object it is. Will a sub-database be a database like any other, simply carrying a link to its parent — which would give it the list, the statistics, the schema explorer and project linking for free? That is the favoured route, but it isn’t decided.
- Write access to the warehouse. The second form needs a permission of its own, and probably an instance-level switch so an administrator can forbid it outright.
In the meantime
Three approaches already cover a good part of the need.
A cohort
Defines the perimeter once and acts as a filter for analyses. See Cohorts.
An ETL pipeline
Already does exactly this, with the filtering queries written by hand: a target database fed from a source one. See ETL pipelines.
A dataset
For an analysis rather than a lasting perimeter: a wide table, already filtered. See Datasets.
Going further
- Databases — what a sub-database will be, once built.
- Cohorts — the criteria builder this feature will reuse.
- ETL pipelines — today’s way of making a derived database.