Mapping Rules Standard

[AndyRae]

Carrot uses its own standard for representing mappings in JSON.

It would be useful to adopt a single standard for OMOP mappings to enable interoperability with other tools.

Ideally mappings created in Carrot, Usagi, Oxford OMOP Data Mapper, by Genomics England, could all be used by Carrot by converting to/adopting this standard.

Ultimately standard mappings could be easier to explore through tooling like OXO, and more advanced registries that make mappings FAIR artefacts.

Goals

• Make Carrot mappings FAIR.
• Increase interoperability with other tools / mappings.
• Provide code architecture for future hub/spoke model.
• Add additional metadata to improve mapping quality, provenance, and understanding.
• Enable mappings to be versioned / stored in registries.

This topic has is raised pretty much every time Carrot is discussed, so we appreciate thoughts, and any possible standards that we could implement.
I do not anticipate replacing the current Carrot standard, but enabling export in a new format.

[AndyRae]

SSSOM

One possible standard is SSSOM, which has gained some use in the OMOP community (paper).
How to gradually enrich OMOP mappings with SSSOM.

Anecdotally - this was the standard mentioned to me several times by others also.

It provides a fairly straightforward rich representation of mappings, and mapping sets. There is some supporting tooling written in Python for validation, representation, and (maybe) deployable registries.
I find the code representation of the models much easier to understand the direction than the documentation.

For example, it would look straightforward to convert a Carrot mapping object to SSSOM, this is probably not much code.

[AndyRae]

For example as its simplest, the CDM rule:

 "observation_concept_id": {
                              "source_table": "Demographics.csv",
                              "source_field": "ethnicity",
                              "term_mapping": {
                                    "Asian": 35825508
                              }
                        },

might convert to:

subject_id	subject_label	predicate_id	object_id	object_label	mapping_justification
ethnicity:Asian	Asian	skos:exactMatch	35825508	Asian	semapv:ManualCuration

But this will also enable the adding further useful metadata such as:

• mapping_date (already captured)
• author_id name/email/preferably orcid
• confidence 0 - 1
• comment (Further context, as in Ability to add documentation to a mapping rule #846)
• mapping_tool (Carrot/Lettuce/Usagi)

And at a Mapping "set" level:

• license (I feel this is a crucial missing element currently)
• mapping_set_version (Version number, as in Mapping Rules Versioning #845 )

There would only be small changes necessary to capture this metadata in the current database.

[AndyRae]

Also here: https://www.ohdsi.org/2024showcase-25/

[AndyRae]

On a technical level it should be noted - a Mapping Rule in the Carrot database is not a reusable artefact, as it is the Scan Report Concepts that are reused.