CDR Tickets

Adding Diana and Margaret.

For the drugs listed in the first two columns (CDR ID, drug name) we basically want to remove all current Drug Reference Blocks with a DrugReferenceType of FDA, and replace them with a single block that has DrugReferenceType of FDA, DrugReferenceLink link title of "FDA label information for this drug is available at DailyMed.", and the DailyMed url (column 3) as the DrugReferenceLink in the attribute inspector.

We want to end up with a single link to DailyMed for each of these drugs. Hope that is clear, but please let me know if it isn't.

The job has been run in test mode on DEV.

https://cdr-dev.cancer.gov/cgi-bin/cdr/ShowGlobalChangeTestResults.py?dir=2018-02-19_10-17-08

Some of the documents aren't on that tier:

CDR791122 not on this tier
CDR791355 not on this tier
CDR781156 not on this tier
CDR787910 not on this tier
CDR791271 not on this tier
CDR788884 not on this tier
CDR791047 not on this tier
CDR790948 not on this tier
CDR788795 not on this tier
CDR790240 not on this tier
CDR790694 not on this tier
CDR786562 not on this tier
CDR788890 not on this tier
CDR790070 not on this tier
CDR788257 not on this tier
CDR784579 not on this tier
CDR787676 not on this tier
CDR790532 not on this tier
CDR785931 not on this tier
CDR790730 not on this tier
CDR780272 not on this tier

Also, CDR779950 couldn't be processed:

CDR779950 missing required EnteredBy element

Without the EnteredBy element, the software doesn't know where to put the new drug reference block.

We have a couple questions:

1. Is the "new" XML in the diff report representative of the order of the DrugReference blocks as they will appear in the document? If so, could we add the FDA block as the first DrugReference block? This is where the FDA block has always been added, so, even though they are rearranged in the vendor filter, it would be helpful to keep that consistency in the CDR.

2. The Diff report shows the removal of all of the DrugReference blocks (not just the FDA ones) and the subsequent addition of most of them unchanged. Sometimes the EnteredBy element is removed and added back in, too. I don't think it really matters, but I was surprised to see so many changes when most of these things should be untouched. It makes it harder to review since we have to make sure everything is added back in. Would it be possible to generate a "cleaner" diff report that just shows the net change?

A couple of answers:

1. I will rewrite the software to put the new block at the top.

2. I'm not using string manipulation to transform the documents (which would be error-prone and unsafe), but a real XML parser. It's not that the parser removed those things and put them back in, it's that the comparison tool is sometimes not as smart as a human would be in detecting what really changed (though to implement the new requirement for question #1 above I may actually need to do just that – remove all the DrugReference blocks and put them back after the new one).

Ah! I responded to what I read in the first JIRA email, not reading your modified version of question #2. We're using the standard Python diff library. If you want us to research replacing that with something more sophisticated, we'll want a separate ticket.

Thanks, Bob. I don't think it's worth changing the diff library.

Live mode run of the rewritten script has finished on DEV. CDR779950 was missing the required Title element, so couldn't be processed.

This looks good on DEV. Looks like CDR779950 is a clinical trial on DEV while it's a DIS on PROD. I think QA will provide a more reliable comparison to PROD given that the data there are more updated. Thanks.

I think QA will provide a more reliable comparison ...

Live mode or test?

You can proceed with the live mode on QA. Thank you!

Live mode completed on QA. Ready for review. CDR791355 is a test document, not a DIS document. The others were modified.

This looks pretty good, although we have a couple of questions:

1) We didn't ask you to add a "description" element for the FDA approval block. I think this is okay, but we'd like to confirm with ~volker that he isn't using this element/text in the vendor filter to inform where the FDA approval link goes on the page. I know we made some fairly recent changes to affect the sequence of related information (see OCECDR-4122).

2) I assume all of these updates will publish to Cancer.gov during the week that you make the changes on PROD. If it isn't too much additional work, could you please update the Date Last Modified in each of the affected documents when you make these changes? Since these are text changes to the doc (not just a URL update like the gov delivery global), we'd like the summaries to have an updated "updated date". Let me know if this isn't feasible.

Thanks!

Unfortunately, we've already run the live mode job on QA and DEV is not very healthy right now, so we only have STAGE on which we can test additional changes. Holding off making any more modifications until ~volker answers the first (implied) question in the previous comment.

I don't know what question to answer. From ~juther comment I thought I would see an element DrugReferenceDescription as part of the FDA reference section but I do not see this on QA.
Should I be looking somewhere else?

That's right, ~volker. The DrugReferenceDescription block is still there as part of the FDA block on PROD (I'll post a screenshot), but with this global change, we no longer have that element in the FDA block. Wanted to make sure this won't cause any problems in the vendor filter before we proceed.

we'd like to confirm with Englisch, Volker (NIH/NCI) [C] that he isn't using this element/text in the vendor filter to inform where the FDA approval link goes on the page.

The filters are using the section attribute of the DrugReference element to determine the position of the FDA link. The DrugReferenceDescription isn't specified by the vendor filters. It's not a problem for this element to be missing for the FDA DrugReference section.

Ok, sounds good. Thanks for confirming!

So is there anything more I need to on this? What's next?

The next steps are for me to rewrite the global change script to incorporate the latest changes in requirements and figure out how we'll test them. I'm working on that this morning.

OK, I have reworked the code to implement the new requirements and to allow the job to run for documents to which the global change had already been applied. I ran it in live mode on QA. Please review.

This looks good on QA. Ready for PROD. If you promote this today, all of the single-agent DIS will publish in tonight's job. ~volker, please let us know if you would prefer that we wait on this until next week.

Any day is OK with me.

The job has been run in live mode on PROD. Please review.

Verified on PROD/Cancer.gov. Thank you!