Add MIM type exceptions to review.tsv

[joeflack4]

Overview

In the Disease-Gene pipeline, we have had some cases where the MIM marked as a phenotype for a given association did not actually have a phenotype as its MIM type.

In 2024/10, OMIM fixed these issues, but we currently have a warning set up to alert if such issues should arise again. However, the review.tsv method is a much better way to alert the team as to when such issues occur.

Sub-tasks

• 1. Put these cases in review.tsv instead of warnings
• 2. Add documentation for the case type(s) in README.md

Additional info

The current warnings:

mim_type_err = f"Warning: Unexpected MIM type {p_mim_type} for Phenotype {p_mim} when parsing phenotype-" \
    f"disease relationships. Skipping."
if p_mim_type in ('OBSOLETE', 'SUSPECTED', 'HAS_AFFECTED_FEATURE'):  # ^, NULL, +
    print(mim_type_err, file=sys.stderr)  # Hasn't happened. Failsafe.
if p_mim_type == 'GENE':  # *
    print(mim_type_err, file=sys.stderr)  # OMIM recognized as data quality issue. Fixed 2024/11. Failsafe.

Related

• GitHub Action for builds: Quick QC check for review.tsv #170

[twhetzel]

@joeflack4 were there additional entries that should be added into the static "review.tsv" in the meantime?

[joeflack4]

@twhetzel Oh, no. That shall not be maintained. I renamed it to "review.tsv - temp for reviewing issue 156". It resides in the subfolder mondo-ingest/issues/by source/omim/156/. It's just a temporary file for that issue.

Not to be confused with this sheet, Self-referential Disease-Gene cases, which I also don't intend to maintain, but is linked in the README.md for illustrative purposes.

[twhetzel]

Ok, but all of the questionable cases that have been found so far will still be added to the "review.tsv" file, correct? And if so, then this should be P0 priority (assuming that is what you are using as the highest level priority).

[joeflack4]

@twhetzel Yeah, they will all be added.

I changed to P0. I made a slack thread asking which was which. I figured that lower was more urgent because it the colors were more red, but what I've done on my project boards is to add low/high text as well to the labels. But I think it's good to have them start with numbers (0, 1, 2) for sorting purposes as you have.

[twhetzel]

I've read over the Slack thread now and priorities are not needed in these tickets since the priority is that if the ticket is on the release board it should be completed for the release cycle. However, if the extra tag is helpful then it can stay. These are not tags that I created.

[joeflack4]

Oh, I see. I suppose there is some kind of project board inheritance, then, for these monthly release ones. What you say makes sense. It's only 1 month but I do like the additional ordering as well, personally. There are some other fields as well, I guess they can basically all be ignored on the monthly boards.