Add lab results mappings for MIMIC-IV v2.0 - SSSOM format

[a-chahin]

This pull request adds two mapping csv files for lab concepts from the d_labitems definitions table in MIMIC-IV v2.0. The first file d_labitems_to_loinc.csv contains itemid to LOINC mappings. There will be a conflict when merging this file to main, as it uses the same file name as an older labs mapping file. This new file contains the latest lab concepts. However, its format is much different. The second file d_labitems_to_omop.csv contains itemid to OMOP mappings.

Both files use the simple standard for sharing ontology mappings SSSOM format @sssom

[tompollard]

Thanks @a-chahin! Same comments as: #1419 (comment), copied below:

• I notice that you have left some of the author_id fields empty for the mappings. I assume this is because we inherited those mappings?
• The documentation at https://mapping-commons.github.io/sssom/author_id/ suggests that author_id is "Recommended to be a (pipe-separated) list of ORCIDs". I think you are currently using commas to separate lists. Should we swap out the commas for |?
• Minor thing, but both files are missing a newline character at the end. This can lead to some tools to ignore the final line. If you are editing the files, we might want to add a newline (just hit return at the end of the final line of each file).

@matentzn hope you don't mind me tagging you here (again!). This file is a mapping for MIMIC-IV concepts. No pressure, but we would appreciate your thoughts on whether anything more should be done to conform to @sssom format.

[matentzn]

Hey, some quick feedback, happy to look this over in more detail if you want (see inline comments as well)

• I think you are using skos:broadMatch the wrong way around: the object is the broader term, see also https://mapping-commons.github.io/sssom/mapping-predicates/
• I get the sense that you are overusing skos:exactMatch a bit, but I lack a bit of context to be sure. I am not sure for example if the units and tissue types provided by the loinc terms are implied by the mimic terms.
• I would recommend setting up a QC system that check for the validity of the sssom file, akin to https://github.com/mapping-commons/mh_mapping_initiative/blob/master/.github/workflows/qc.yml

[matentzn]

mapping_justification uses invalid values, yours should be semapv:ManualMappingCuration, see https://github.com/mapping-commons/sssom/blob/master/src/sssom_schema/schema/sssom_schema.yaml#L211

[a-chahin]

Thank you! I will update the tables.

[matentzn]

orcids should be pipe separated

[a-chahin]

Thank you! This will be corrected in the updated files.

[matentzn]

Is there a reason confidence is only sometimes curated? Its not wrong, just wondering from a user perspective how I would interpret the absence of a value for confidence.

[a-chahin]

The mapping was done before we were aware of the SSSOM standard. This is just the initial release for mapping files. In the next step, I will go over the mappings to check for any deprecated codes and I will add a confidence score for the rest of concepts.

[matentzn]

Invalid record according to sssom, do you intend to say "there is no exact mapping?"

[a-chahin]

It depends. For example, itemid 52036 is for the concept "Voided Specimen" which is not a lab test.
Other concepts have ambiguous labels that don't make any sense.
Do you think I should use "there is no exact mapping" for all unmappable concepts regardless of the reason?

[matentzn]

This is an interesting question for the sssom issue tracker https://github.com/mapping-commons/sssom/issues because what we usually do in this case is not include the subject entity at all in the mapping file. If there is no mapping there is no mapping. However, I can see how your desire to have an entry for all subject entities in MIMIC makes sense. In this case, we usually define the predicate_id (e.g skos:exactMatch) and then add a placeholder, sssom:NoTermFound, see mapping-commons/sssom#28 for a discussion on the subject. This will allow us to also later say: there is no broad/narrow match easier. However, for your case, this solution is not perfect, because you really want to say something like "out of scope", but that's not currently possible to express, so maybe make an issue?

[tompollard]

Thanks @matentzn, I think you're right that sssom:NoTermFound isn't quite what we need. @a-chahin give me a shout if you'd like to discuss this before raising the issue. Something like an OutOfScope tag sounds good to me!

[tompollard]

I have just raised an issue at mapping-commons/sssom#245

[tompollard]

@matentzn Many thanks for your quick and helpful feedback. I appreciate you spending the time to do this! We will work on addressing the points that you've raised.

[a-chahin]

Hey, some quick feedback, happy to look this over in more detail if you want (see inline comments as well)

• I think you are using skos:broadMatch the wrong way around: the object is the broader term, see also https://mapping-commons.github.io/sssom/mapping-predicates/
• I get the sense that you are overusing skos:exactMatch a bit, but I lack a bit of context to be sure. I am not sure for example if the units and tissue types provided by the loinc terms are implied by the mimic terms.
• I would recommend setting up a QC system that check for the validity of the sssom file, akin to https://github.com/mapping-commons/mh_mapping_initiative/blob/master/.github/workflows/qc.yml

Hey, some quick feedback, happy to look this over in more detail if you want (see inline comments as well)

• I think you are using skos:broadMatch the wrong way around: the object is the broader term, see also https://mapping-commons.github.io/sssom/mapping-predicates/
• I get the sense that you are overusing skos:exactMatch a bit, but I lack a bit of context to be sure. I am not sure for example if the units and tissue types provided by the loinc terms are implied by the mimic terms.
• I would recommend setting up a QC system that check for the validity of the sssom file, akin to https://github.com/mapping-commons/mh_mapping_initiative/blob/master/.github/workflows/qc.yml

Thank you so much for the valuable information @matentzn.

• I will double check all skos:broadMatch under predicate_id to make sure they are correct.
• I used skos:exactMatch when the label, fluid, and unit of measurement in MIMIC matches LOINC.
• I will check with Tom to setup a QC system.

[tompollard]

I will check with Tom to setup a QC system.

Let's have a chat about this. In a separate pull request, it looks like we'll need to:

1. Add a "validate_mappings" rule to either a Makefile or to our Pytest code (need to work out where the validation code lives!).
2. Add a validation rule to our github workflow that references the rule, based on the one at https://github.com/mapping-commons/mh_mapping_initiative/blob/master/.github/workflows/qc.yml

[a-chahin]

@matentzn I wanted to get your opinion on the most appropriate mapping_justification for medications data in MIMIC. We used a script written by @xborrat to automate the mapping of 5000+ medications from NDC to RxNorm utilizing the OMOP data model. NDC codes are mapped to OMOP concept IDs and then, using the non-standard to standard relationship, to RXCUIs for RxNorm. We the spot-checked the mappings to validate the results. Is semapv:MappingChaining the correct mapping justification?
Thank you for your help!

[matentzn]

@a-chahin There are no 100% matured guidelines here. I would recommend using semapv:MappingChaining only when two already established mappings are combined. If there is a mapping justification and semantic mapping predicate for NDC->OMOP (i.e. semapv:LexicalMatching, and skos:exactMatch) and the same for OMOP->Rxnorm (which afaik there is not, because OMOP standard to non standard is "exact or broad", with no way to know which is which, and no formal justifications combined).

Its tough in your case. Depending on the mapping predicate you use for the NDC->RxNorm mapping, maybe semapv:MappingChaining is ok, but then I would make a comment in the mapping set metadata saying how the chaining exactly was applied (e.g. how you interpreted the OMOP NS-S mappings).

Thanks for the great question! If you could use the sssom issue track for some of these, others would be able to chime in as well!

[a-chahin]

Thank you @matentzn for your reply! I will create an issue on the SSSOM GitHub page.

[Chessing234]

this has been open since november 2022 and the ground has moved under it.

mimic-iv/concepts/concept_map/d_labitems_to_loinc.csv doesn't exist on main any more — "refactor mimic-iv SQL queries into subfolders of concepts" reorganised that directory, which now holds chartevents_to_loinc, chartevents_to_omop, procedureevents_to_omop and procedureevents_to_snomed, with lab mappings living under a hosp/ subfolder (see the paths in #1930). so the merge conflict you predicted in the description isn't the filename collision you were expecting; it's that the layout changed.

that also means the "newer file supersedes the older one" reasoning needs rechecking against what's actually on main today, four years of mappings later — d_labitems has changed across MIMIC-IV releases since v2.0.

worth deciding explicitly whether this is still wanted rather than leaving it open: either rebase onto the current layout with a note on how it relates to the lab mappings in #1930, or close it. a four-year-old conflicting PR costs a maintainer the same triage attention as a live one every time they scan the queue.

i can't verify the mappings themselves — no MIMIC-IV access here.