Summary
The Overview aggregates every mapping in the workspace into a single page. Use it to track global progress, deduplicate concepts that appear in several projects, assign source_concept_id values, and generate the consolidated source_to_concept_map file that feeds an OMOP ETL — typically at hospital or consortium scale.
Why this view?
Splitting the mapping work into several projects is often the best approach: one project per category (Conditions, Drugs, Measurements…), one per source (lab, prescription, EHR…), or one per study. But once the work is split, you need to piece it back together — that’s what the Overview does.
Tip — map only what you need, project by project
Mapping an entire hospital database often feels overwhelming: thousands or tens of thousands of concepts, and the effort seems disproportionate to the time available.
An effective strategy: don’t try to map everything at once. Start each study or use case as its own mapping project, scoped to the concepts strictly needed (typically a few dozen up to a hundred). You gain interoperability where it matters, without carrying the weight of an exhaustive mapping.
Over time, project after project, your database is mapped progressively — and the Overview shows you the cumulative coverage.
Two typical scenarios
One hospital, several projects
You split your hospital’s mapping into several projects to organise the work better (e.g. a “Biology” project, a “Drugs” project, a “Diagnoses” project). Projects may overlap: the same source concept sometimes appears in several files, and therefore in several projects.
The Overview lets you:
- see at a glance where mapping stands, across all projects ;
- group mappings by badge (the hospital’s badge) — Linkr then deduplicates identical
(source code, target concept)mappings that appear in several projects, indicating the number of projects each one comes from ; - produce a consolidated
source_to_concept_mapexport without having to concatenate project-by-project exports.
When it’s time to produce the ETL, you group by the hospital’s badge, assign source_concept_id values across the whole set (see below), and export a single source_to_concept_map file containing all the mapping work done for that hospital.
Several hospitals, a shared workspace
Multiple institutions contribute to the same workspace, each with their own badge (Hospital A, Hospital B…). Each hospital works on its side, in its own projects.
The specific challenge here is around source_concept_id values: if each hospital assigns them independently (e.g. in separate workspaces), you risk collisions when centralising data — two hospitals using the same OMOP custom ID for different concepts. The Overview centralises ID assignment: each badge (each hospital) gets its own disjoint range.
You also benefit from the same features as the previous scenario: a consolidated table of every mapping, filterable by badge, exportable as a single source_to_concept_map covering all hospitals.
The Source Concept IDs registry
A source_concept_id is the numeric ID that OMOP expects in the source_to_concept_map table for each source concept. If your original file doesn’t carry this ID (typical for a CSV with just a label and a code), Linkr can assign one automatically in the OMOP custom range (2,000,000,001 to 2,147,483,647).
A concrete example
Imagine a shared workspace mixing both scenarios above. Three projects coexist:
- Hospital A splits its mapping into two projects, by category: one for biology (
d_labitems.csv), one for drugs (d_drugitems.csv). Both carry theHospital Abadge. - Hospital B has mapped its full local terminology in a single, completed project. It carries the
Hospital Bbadge.
To prepare the export, you assign a different range to each badge — typically one range per hospital. Linkr suggests the next free range in the OMOP custom space, which you can accept or adjust:
Assign stable custom OMOP IDs to source concepts that don't have an ID column. IDs are deterministic per (vocabulary, code) pair and persist across sessions.
Valid OMOP custom range: 2,000,000,001–2,147,483,647(max INT32, compatible with OMOP INTEGER columns)
Badge ranges
For Hospital A, source concepts that appear in both projects (biology and drugs) receive a single source_concept_id — taken from the range 2,000,000,001 – 2,001,000,000. No duplication, even if a “Diagnoses” project is added later sharing concepts with the first two.
For Hospital B, IDs are assigned in the next range (2,001,000,001 – 2,002,000,000), fully disjoint from Hospital A’s. Both datasets can later be centralised without any collision risk on source_concept_id values.
How it works
The registry works per badge:
- Each badge gets a sub-range of IDs (1,000,000 IDs by default).
- Within a badge, the same
(vocabulary, code)always gets the samesource_concept_id, regardless of which project it appears in — that’s what enables deduplication across projects of the same hospital. - Across badges, ranges are disjoint — no collision possible when centralising data from multiple hospitals.
Click Assign IDs on a badge row once mapping is done. The registry is populated, then re-export your STCM to get non-zero source_concept_id values.
Other tabs
The Overview is organised in four tabs. Source IDs is detailed above; here are the three others:
Summary
Aggregated KPIs (source concepts, mapped, approved, flagged, ignored) across all projects, and stacked bars comparing progress across projects or grouped by badge. This view answers “where does the workspace stand overall?”.
Table
Flat table of every mapping in the workspace, with filters by project, badge, vocabulary and status. This is the view to inspect mappings row by row, spot overlaps between projects, and quickly find a specific alignment.
Export
Same formats as the Export tab of an individual project, but applied to the whole workspace. Handy for producing a single ETL file covering all projects of a hospital — or several hospitals when consolidating.
This is where you generate the `source_to_concept_map` file for an OMOP ETL
To produce the source_to_concept_map file that feeds your OMOP ETL, use the Export tab of the Overview — rather than the Export tab of an individual project.
This is the level where source_concept_id values have been assigned (one range per badge, without collision) and where identical mappings appearing in several projects have been deduplicated. The consolidated export drops straight into an ETL pipeline, without any post-processing.