CDR Tickets

Revised Glossary Terms_01-09-19.xlsx
I have attached another spreadsheet containing Spanish terms that have been revised since we started displaying the term name as part of the friendly URL. I haven't checked every single one of them since there are a lot. It seems to me, however, that we need to find a sustainable approach to this problem because we make a lot of term name changes and keeping track of the changes manually is going to be difficult.

Preferred Name Changes.xlsx

I am attaching a list of drug terms with the same problem as the glossary terms. That is, the names in the URL do not match the preferred names.

~oseipokuw, you are listing the term names in the spreadsheet but not the URL that needs to update the current display. Of course, for some of these terms it is a no-brainer, changing alkeran-tablets to alkeran but what should the URL be for stage III nonmelanoma skin cancer on the head and neck (not on the eyelid) which is currently stage-iii-nonmelanoma-skin-cancer?

That is because we do not know the URLs for the terms. I know they mostly include the term names but it may not be in all cases. That is one more reason why this should be handled programmatically.

Who would know the URL for the terms? Obviously, I'm unable to make any manual changes to the incorrect URL if I don't have the new, correct URL available.

If you meant this ticket to handle the automated change then we shouldn't mark its component as Data Fixes and it should be part of the WCMS Dependencies bucket.

From last Thursday's meeting ~sunvw was going to look into this and let us know how the URLs could be updated as the titles are changed.

OK, let's discuss on Thursday how to go forward with this ticket.

This isn't something we will be able to address before the Migration. OCEPROJECT-5020 was entered in the backlog

I am attached the list of revised glossary terms for January '19.
Revised Glossary Terms - January 2019.xlsx

There isn't a quick manual update that can be done for URLs to be changed to the new terms. We will need to address the underlying programmatic fix post-migration and do a cleanup at the time we make that update.

As discussed at our status meeting I've looked at about 50% of the terms listed on William's latest glossary term spreadsheet and all of those terms display the URL that's based on the name listed on that spreadsheet.

We've also checked several terms including most recent changes and the names in the URLs do match the term names. It looks like the problem is resolved.

I was in the process of closing the ticket but I realized that this affects both the Glossaries and the Drug Dictionary. While the problem is fixed for the glossaries, the drug dictionary still exhibits the problem. So, I am going to leave this ticket open until work on the drug dictionary gatekeeper migration is complete. Here are two examples. 

https://www.cancer.gov/publications/dictionaries/cancer-drug/def/pdgfr-alpha-kit-mutant-specific-inhibitor-blu-285

https://www.cancer.gov/publications/dictionaries/cancer-drug/def/dna-pk-inhibitor-msc2490484a

That is correct.  The drug dictionary hasn't switched over to the new API yet.  For now only the glossaries are using the new API.

Also, as Bob mentioned, there still is a problem with super-long term names.  I'm guessing this does primarily affect the drug dictionary.

I'm assuming this is the same situation as the one I had mentioned in my comment for OCECDR-4027.  My guess is that the new drug API is not necessary to be installed for this fix and the recent release to eliminate the Gatekeeper processing steps will have taken care of the requested changes to have URLs updated for renamed drug terms.

If you can confirm my assumption, ~oseipokuw, we can close this ticket.

~volker  I reviewed the two examples above and the URLs still have the former preferred names for the drug terms so it looks like the problem still persists.

Please include your example to ensure we're looking at the same thing.

Here they are: They are the same examples in one of my comments above.

https://www.cancer.gov/publications/dictionaries/cancer-drug/def/pdgfr-alpha-kit-mutant-specific-inhibitor-blu-285

https://www.cancer.gov/publications/dictionaries/cancer-drug/def/dna-pk-inhibitor-msc2490484a

It appears the correct data for changing the pretty URL is already being created correctly (and loaded to Elastic Search) but that data is not yet used in production, so you're correct, ~oseipokuw.  However, I would probably not want to use this term as a test

https://www.cancer.gov/publications/dictionaries/cancer-drug/def/dna-pk-inhibitor-msc2490484a

The term is listed in your spreadsheet with the new name nedisertib.  The pretty-URL gets build from the name in the EVS and the preferred name for this drug (C-code: C767372) is peposertib, so that would be the new URL for the drug.

Now that the Drug Dictionary API is used on Cancer.gov I believe this ticket is mute.  With the new API the pretty URL for a drug is now independent of the preferred name in the CDR.  Instead, the pretty URL is now created based on the name listed in the NCI Thesaurus.  For instance, the new preferred name for CDR760532 in the CDR is "larotrectinib sulfate".  It's preferred name in the Thesaurus is "Larotrectinib".  Therefore the pretty URL name for this drug is "larotrectinib".  That is the same for other drugs I see on your spreadsheet like

• calaspargase Pegol-mknl

• ravulizumab-cwvz

• talazoparib tosylate

If you agree, ~oseipokuw, please go ahead and close this ticket.

Yes, that is what I see and it seems all the examples above are using the name from the NCI thesaurus so I am closing this ticket. Thanks!