Export

The page is split into two blocks: a filter at the top decides which mappings will be exported, and a grid of four cards below — one per format. The export count updates live as you change the filter, and each card downloads its version on click.

Export filters

Statuses to include

At the top, one checkbox per effective status, with the project count for that status next to it. Five rows, in this order:

• Approved — mappings validated by reviewers. Checking this box reveals three sub-options that specify what counts as “approved” in the context of multi-reviewer voting:

  • At least one approval — most permissive. A single “approved” vote is enough, even if there are also rejections on the same mapping.
  • More approvals than rejections — simple majority. A reasonable compromise for a team with multiple reviewers.
  • No rejections — strictest. A single “rejected” vote excludes the mapping, regardless of how many approvals it has.

  The rule is applied per source concept: Linkr groups all votes posted on every (source, *) mapping for the same source code, then applies the rule on the total.

• Rejected — mappings rejected by one or more reviewers.

• Flagged — mappings flagged (flagged vote) for discussion.

• Unchecked — mappings created but with no vote yet.

• Ignored — mappings flagged as “no match” (target = 0, or ignored status).

By default, only Approved is checked, with the rule “At least one approval” — that’s the most common output: the consolidated mapping, ready for production. You can tick several statuses to produce a wider export (for example Approved + Flagged to share between reviewers).

Include all source concepts

Below the filter, separated by a divider, an independent checkbox: “Include all source concepts”. Next to it, a badge shows how many source concepts would be appended if it were enabled (those that don’t appear in any filtered mapping above).

This option mainly exists for the STCM export feeding an OMOP ETL. The source_to_concept_map table should ideally contain one row per source concept of your database, including those that don’t (yet) have a standardised target — otherwise your ETL won’t be able to convert their source_concept_id to anything, and will lose the information at the join. Ticking this box appends unmapped concepts with target_concept_id = 0, but with their source_concept_id correctly assigned — which is precisely what makes the export usable.

In practice, the option adapts the format of each export:

• STCM — appends missing concepts with target_concept_id = 0.
• SSSOM — appends missing concepts with object_id = sssom:NoTermFound (cardinality 1:0).
• Usagi — appends missing concepts with mappingStatus = UNCHECKED, equivalence = UNREVIEWED.

Export total

At the very bottom of the filter, the Export total counter sums the filtered mappings and the unmapped source concepts appended. That’s the number of rows that will end up in the exported file.

The four formats

The format cards are always visible. Each card’s Download button is disabled when the export total is zero (except for Linkr ZIP, which is always downloadable — see below).

Linkr ZIP

The complete and re-importable archive for another Linkr instance — the format for backup and sharing between Linkr instances. Contents:

• project.json — the full project object (metadata, badges, configuration, minus the raw source file handled separately).
• mappings.json — all mappings in Linkr’s internal format (see Evaluation → Structure of mappings.json).
• source-concepts.csv — the project’s source concepts, always as a CSV:
  • for a file-based project, it’s the raw source file as imported;
  • for a database-based project, it’s the result of the source query materialised as CSV — DuckDB runs the query defined in the project’s schema mapping, and Linkr writes the rows into the ZIP. No SQL exported, no connection kept: just the data frozen at export time.

The Linkr ZIP button ignores the status filter: it always exports every mapping in the project, because it’s the backup — you want to recover everything if you re-import.

SSSOM TSV

SSSOM (Simple Standard for Sharing Ontological Mappings) is the interchange standard for ontology mappings, supported by the biomedical community (Monarch Initiative, OBO Foundry, OHDSI…).

YAML header

The file starts with a metadata header in YAML format — each line prefixed by #:

• curie_map — declares the prefixes used in the file. A CURIE (Compact URI, W3C convention) is a URI written in abbreviated form prefix:local_identifier instead of the full URI. The curie_map binds each prefix to its base URI, which lets an SSSOM consumer understand that skos:exactMatch means http://www.w3.org/2004/02/skos/core#exactMatch, or that OHDSI:4353843 means http://ohdsi.org/concept/4353843. Linkr declares skos, semapv, sssom and OHDSI.
• mapping_set_id — the unique identifier of the Linkr mapping project.
• mapping_set_title — the project’s human-readable name.
• mapping_date — the export date, in YYYY-MM-DD format.
• license — the mapping set’s licence. Linkr emits CC0 1.0 (Creative Commons Zero, https://creativecommons.org/publicdomain/zero/1.0/): the mapping is released into the public domain, freely reusable without attribution. You can edit this line before publication if you want a different licence.

Table columns

Then a tab-separated table with these twelve columns:

• subject_id — the source concept’s identifier, as a CURIE (e.g. MIMIC-IV:50912).
• subject_label — the source concept’s label (e.g. Creatinine).
• subject_source — the source concept’s vocabulary (e.g. MIMIC-IV).
• predicate_id — the SKOS equivalence between source and target: skos:exactMatch, skos:closeMatch, skos:broadMatch, skos:narrowMatch, skos:relatedMatch. Directly carries the equivalence chosen in Linkr.
• object_id — the target concept’s identifier, as a CURIE (e.g. OHDSI:3016723). For a mapping with no target (ignored or target_concept_id = 0), the value is sssom:NoTermFound — per the SSSOM spec.
• object_label — the target concept’s label.
• object_source — the target vocabulary (e.g. LOINC, SNOMED). For a NoTermFound, Linkr defaults to OHDSI to indicate where the search happened.
• mapping_cardinality — the mapping cardinality. For a target-less mapping, equals 1:0. Empty otherwise (multi-cardinalities are not exposed in Linkr).
• mapping_justification — the mapping’s justification, in semapv:* format (SEMAPV vocabulary). Linkr emits semapv:ManualMappingCuration for reviewed mappings (approved, flagged, rejected, ignored) and semapv:UnspecifiedMatching for unreviewed ones.
• confidence — the match score (0 to 1) inherited from the pre-ranking, if available.
• author_id — the mapping’s author in Linkr (or the automated method: Syntactic, BioLORD, Claude Sonnet…).
• comment — the mapping’s comments, joined by |.

This is the right choice to publicly share a mapping or contribute to a cross-institution project.

OMOP STCM CSV

The OMOP CDM format for the source_to_concept_map table, directly importable into an OHDSI ETL. One row per (source, target) pair. The nine columns (source_code, source_concept_id, source_vocabulary_id, source_code_description, target_concept_id, target_vocabulary_id, valid_start_date, valid_end_date, invalid_reason) are described in the table reference.

Linkr sets valid_start_date to 1970-01-01 and valid_end_date to 2099-12-31 (full validity); invalid_reason is left empty.

Usagi CSV

Format compatible with Usagi, OHDSI’s traditional concept-mapping tool. The file mirrors the seventeen columns of Usagi’s WriteCodeMappingsToFile:

• sourceCode — the source concept’s code.
• sourceName — its label.
• sourceFrequency — the observed frequency of the concept in the source (record count), if provided.
• sourceAutoAssignedConceptIds — the native source_concept_id (if any), otherwise 0.
• matchScore — the match score (0 to 1) inherited from the pre-ranking, if available.
• mappingStatus — the Usagi status (see mapping below).
• equivalence — the Usagi equivalence level (see mapping below).
• statusSetBy — the author of the current status.
• statusSetOn — the date of the current status, as a Unix timestamp in milliseconds.
• conceptId — the OMOP id of the target concept (0 if no target).
• conceptName — the target concept’s label.
• domainId — the OMOP domain of the target concept (Measurement, Condition, Drug…).
• mappingType — the Linkr mapping type, uppercased.
• comment — the mapping’s comments, joined by |.
• createdBy — the mapping’s author.
• createdOn — the creation date, as a Unix timestamp in milliseconds.
• assignedReviewer — the reviewer explicitly assigned to the mapping, if any.

Status mapping (Linkr → Usagi)

SKOS equivalence mapping (Linkr → Usagi)

Useful if you work back-and-forth with a team that uses Usagi, or to deposit a mapping in a standard OHDSI repo.

ETL integration

Once source_to_concept_map.csv is exported, you can inject it into the ETL pipeline of your Linkr warehouse:

1. In Data Warehouse → ETL → Vocabulary, import the STCM file.
2. Linkr generates a 00_vocabulary.sql script that populates the source_to_concept_map table of your target OMOP database.
3. That script slots into the rest of your ETL pipeline (patient data transformation, etc.).

Concept mapping then becomes the pivot between your raw data and a usable OMOP warehouse. For a consolidated export across multiple projects — typically a whole hospital — go through the Global view instead, which deduplicates identical mappings across projects and assigns source_concept_ids without collisions.