Waldenström's Macroglobulinemia is not liked to a DOID

[jsaliba10]

Waldenström's Macroglobulinemia is not linked to a DOID, but it does have one (DOIS 0060901) assigned in the disease ontology database (https://disease-ontology.org). Not sure if matters, but in the DO database, 'o' is used instead of 'ö' in the spelling of the name.

Also, clicking on Waldenstrom's Macrobulinemia in the disease field brings the user to CIViC and not to the DO page.

Example EID986

[susannasiebert]

If the disease name differs from the one used in the DO, you should be able to edit this disease entry in the admin console to make the names match up. There, you can either also fill in the DOID manually or you can wait for the scraper to pick it up next time it runs.

For the linking issue, that something that needs to be addressed on the frontend. Paging @jmcmichael

[kkrysiak]

Check in the admin console, we may have assigned this one manually or something similar. This was a term change we requested of DO. https://github.com/DiseaseOntology/HumanDiseaseOntology/issues/264

[jsaliba10]

I added the DOID manually through the admin console. The Waldenström's Macroglobulinemia link now goes to the proper DO page.

Susi, thanks for the Information that these things can be modified in the admin interface.

Could the o vs the ö be why it was unliked?

[susannasiebert]

yes, the o vs ö would've been the problem as the scraper tries to find exact name matches. Since you manually associated the DOID, I believe the scraper will "fix" the name to match what the DO has for it, next time it runs.

[jmcmichael]

Is there a way that the server could return null instead of an empty string for this condition? Currently the evidence summary (and maybe other views) assumes that if disease.doid is not null then it should display the disease as a link instead of just plain text. In this case, the disease DOID was returned as an empty string.

[kkrysiak]

I believe I copied the name from DO originally as one of the synonyms in order to avoid matching issues but it makes sense to drop the umlaut to avoid matching issues with many resources. Oops.

[susannasiebert]

huh, I wonder if this is a case where the DOI was "deleted" at some point. There are definitely nil and empty string values in the database currently.

[acoffman]

I believe we are already returning the link if its a valid DOID or null if not for the URL:

https://github.com/griffithlab/civic-server/blob/staging/app/presenters/disease_presenter.rb#L18

[kkrysiak]

Looking at it, WM is still listed as an alias for LPL. I wonder if this is contributing to the confusion.

[susannasiebert]

Unfortunately, the current scraper doesn't remove aliases, it just adds new ones. Is that something we want it to do (e.g., keep aliases totally in sync with DO even if that means removing old aliases)?

[kkrysiak]

This sounds like a discussion for meeting tomorrow. Could you pull a list of aliases that no longer exist / are changed between DO and our current state?

[jmcmichael]

I believe we are already returning the link if its a valid DOID or null if not for the URL:

https://github.com/griffithlab/civic-server/blob/staging/app/presenters/disease_presenter.rb#L18

Ah, ok - I need to switch to testing the url parameter instead of the doid for that logic - it's a remnant for when the client used to construct the URL in the template.

[susannasiebert]

I went ahead and set all doid "" (empty string) values to nil. I also noticed that we have some diseases in the database multiple times ("Solid Tumor" was in our database over 200 times). I deleted the duplicate entries as well.

[susannasiebert]

The DOID issue has been addressed and the link issue will be addressed in #1460