CDR Tickets

BZDATETIME::2011-01-04 11:21:01
BZCOMMENTOR::Bob Kline
BZCOMMENT::1

Looks like some of these have been dropped by NLM:

NCT00678223
NCT00499772
NCT00955019

BZDATETIME::2011-01-05 11:18:09
BZCOMMENTOR::William Osei-Poku
BZCOMMENT::2

(In reply to comment #1)
> Looks like some of these have been dropped by NLM:
> NCT00678223
> NCT00499772
> NCT00955019

That is correct for:
> NCT00499772
> NCT00955019
They are both completed on the NLM web site. The above two trials have Active statuses in the CDR. If we do a force download, would their statuses update?

However, the new ID for NCT00678223 is NCT00678769
Please direct all updates from NNCT00678769 to CDR595388.

BZDATETIME::2011-01-05 13:21:36
BZCOMMENTOR::Bob Kline
BZCOMMENT::3

I have tried to determine what needs to happen for each of these cases. It was fairly complicated, partly because the situations were different from case to case, and partly because some of the information reported did not represent instructions for me to do anything, as far as I could tell (the notes about documents which had been marked as duplicate, for example). So I strongly suggest that after tomorrow morning's download and import jobs have completed CIAT examine the documents for each one of these trials very carefully to make sure that what they wanted to have happen actually did happen.

Note to self: SQL queries used for this task checked into svn at /trunk/Utilities/issue4975.sql.

BZDATETIME::2011-01-06 10:02:30
BZCOMMENTOR::William Osei-Poku
BZCOMMENT::4

The following seems not to have been updated. It still has the original NCT ID (NCT00078546) in the CDR. The current Active NCT ID is:NCT00608257.

>4. CDR 360874
>current NCT ID: NCT00078546 is obsolete.
>new NCT ID: NCT00608257
>Direct all updates from NCT00608257 to CDR 360874

The NCT IDs for the following have been switched. The Active NCT ID should be NCT00037817.

>7. CDR 69448
>current NCT ID: NCT00041158
>new NCT ID: NCT00037817
>Direct updates from NCT00037817 to CDR 69448

BZDATETIME::2011-01-06 11:10:10
BZCOMMENTOR::Bob Kline
BZCOMMENT::5

(In reply to comment #4)
> The following seems not to have been updated. It still has the original NCT ID
> (NCT00078546) in the CDR. The current Active NCT ID is:NCT00608257.
>
> >4. CDR 360874
> >current NCT ID: NCT00078546 is obsolete.
> >new NCT ID: NCT00608257
> >Direct all updates from NCT00608257 to CDR 360874

Hard to say what to do with this one. The download software comes to the conclusion that it needs to skip over this trial because it is "owned by PDQ as CDR582383." That's because NLM's document has 'CDR0000582383' as the text content of the org_study_id element, and that CDR document doesn't have a transfer block, and is not a CTGovProtocol document. Here are the possible ways around this problem that I can think of:

1. Add a transfer block to CDR582383
2. Rewrite the download software logic to decide that the trial is not
owned by PDQ if the CDR document in the org_study_id is blocked
3. Rewrite the download software to hard-code special handling for this
trial
4. Get NLM to remove or movify the org_study_id element.

Option #4 seems pretty unlikely to succeed. Option #3 is a very bad idea, for obvious reasons. Option #2 might have unintended (and unwanted) side effects (for example, causing us to import trials for which we already have a document which is temporarily blocked, for one reason or another). I can't think of any problems with the first option, but you'd be in a better position to know of such problems than I would. By the way, wouldn't we normally just use CDR582383 for the new CTGovProtocol in a case like this (a fifth option)? Why isn't that being done here?

> The NCT IDs for the following have been switched. The Active NCT ID should be
> NCT00037817.
>
> >7. CDR 69448
> >current NCT ID: NCT00041158
> >new NCT ID: NCT00037817
> >Direct updates from NCT00037817 to CDR 69448

The first thing the download job does is to take a file we got from Lakshmi back in December 2003, containing a list of duplicates, and make sure all of those trials have 'duplicate' as their disposition. So although I manually adjusted the row in the ctgov_import table to match your request, my adjustment was overridden before we ever got to the document from NLM. Should I:

1. Remove that row from the 'duplicates' file?
2. Empty the 'duplicates' file?
3. Rewrite the download software to no longer perform that preliminary step?
4. Rewrite the software to avoid marking this particular trial?

Again, #4 is as unattractive as the hard-coding described in option #3 of the previous list.

BZDATETIME::2011-01-06 12:06:39
BZCOMMENTOR::William Osei-Poku
BZCOMMENT::6

These two trials have a completed status (on ct.gov) and they are not going to go on cancer.gov. Our only problem is that they are displaying on the orphaned ctgov protocols. So I guess there is no need to spend so much time modifying the download software. For now, I think it is OK for them to show up on the report. If we continue to have a lot of these trials, we can put in a request to modify the report not to display them.

BZDATETIME::2011-01-06 14:22:55
BZCOMMENTOR::Bob Kline
BZCOMMENT::7

Following up on decisions made in this afternoon's project status meeting, I have re-adjusted the disposition for NCT00037817 and removed the row for that trial from Lakshmi's list of duplicates. I also dropped the row in the table for NCT00608257, and William will have a transfer block added to InScopeProtocol document CDR582383 (solution #1 above), which should cause the document to be converted to a CTGovProtocol document, and the trial should drop off the report.

BZDATETIME::2011-01-06 15:16:08
BZCOMMENTOR::William Osei-Poku
BZCOMMENT::8

For # 5 below, I failed to provide you the new NCT ID. Sorry. The new NCT ID is
NCT00488592. So all updates coming from NCT00488592 should be directed to CDR 558028 and NCT00499772 could be designated as the NCT Alias.

>5. CDR 558028
>current NCT ID: NCT00499772
>new NCT ID: NCT00499772
>Direct all updates from NCT00499772 to CDR 558028
>NCT00488592 is marked as duplicate

BZDATETIME::2011-01-06 16:28:54
BZCOMMENTOR::Bob Kline
BZCOMMENT::9

(In reply to comment #8)
> For # 5 below, I failed to provide you the new NCT ID. Sorry. The new NCT ID is
> NCT00488592. So all updates coming from NCT00488592 should be directed to CDR
> 558028 and NCT00499772 could be designated as the NCT Alias.

The rows for this trial have been updated. Please check tomorrow morning to confirm that the download and import have done what you wanted for this trial as well as the two cases from comments #5 and #7.

BZDATETIME::2011-01-06 16:53:42
BZCOMMENTOR::William Osei-Poku
BZCOMMENT::10

(In reply to comment #7)
> for NCT00608257, and William will have a transfer block added to
> InScopeProtocol document CDR582383 (solution #1 above), which should cause the
> document to be converted to a CTGovProtocol document, and the trial should drop
> off the report.

This is done. We will monitor the trial tomorrow to see if the changes were done.

BZDATETIME::2011-01-07 10:58:54
BZCOMMENTOR::William Osei-Poku
BZCOMMENT::11

(In reply to comment #10)
> (In reply to comment #7)
> > for NCT00608257, and William will have a transfer block added to
> > InScopeProtocol document CDR582383 (solution #1 above), which should cause the
> > document to be converted to a CTGovProtocol document, and the trial should drop
> > off the report.
>
> This is done. We will monitor the trial tomorrow to see if the changes were
> done.

The trial did not convert as expected. It rather showed up as a new trial to be reviewed (and imported).

BZDATETIME::2011-01-07 15:16:37
BZCOMMENTOR::Bob Kline
BZCOMMENT::12

I plugged in the CDR number for existing document, and we can see what happens during the next import job.

BZDATETIME::2011-01-10 10:26:53
BZCOMMENTOR::William Osei-Poku
BZCOMMENT::13

(In reply to comment #12)
> I plugged in the CDR number for existing document, and we can see what happens
> during the next import job.

I just checked it this morning and it has still not converted into a ctgov document. The document is blocked from publication but it looks like that should not be a problem.

BZDATETIME::2011-01-10 17:08:13
BZCOMMENTOR::Bob Kline
BZCOMMENT::14

Well, I have no idea how the disposition got from 'import requested' to 'imported' without the import actually happening, but I made sure that didn't happen again by running the import job by hand, and the conversion succeeded. Take a look.

BZDATETIME::2011-01-11 11:05:57
BZCOMMENTOR::William Osei-Poku
BZCOMMENT::15

(In reply to comment #14)
> Well, I have no idea how the disposition got from 'import requested' to
> 'imported' without the import actually happening, but I made sure that didn't
> happen again by running the import job by hand, and the conversion succeeded.
> Take a look.

It doesn't look like it worked. CDR582383 remains an InScope document but CDR0000360874 got updated yesterday. Meanwhile, both CDR582383 and CDR0000360874 have the same NCT ID - NCT00608257, and CDR0000360874 has CDR0000582383 as the OrgStudyID.

BZDATETIME::2011-01-11 12:05:40
BZCOMMENTOR::Bob Kline
BZCOMMENT::16

I believe CDR582383 is now correctly converted. I think you can go ahead and block CDR360874.

For future requests to clean up garbled CT.gov protocol duplicate cases, it would probably be easier to avoid confusion, particularly when the complete set of instructions has to be merged from separate comments as the issue progresses, if a separate Bugzilla task were created for each set of cases which need to be handled exactly the same way (this issue had a mixture of various conditions which had to be dealt with differently, and I got hopelessly lost more than once). If it's not easy to tell which cases represent the same condition, even though it seems cumbersome, it would be very helpful if a separate task were created for each trial. These problems are complicated enough even when we don't bundle together different conditions in the same cleanup task.

Thanks!

BZDATETIME::2011-01-12 14:18:42
BZCOMMENTOR::William Osei-Poku
BZCOMMENT::17

(In reply to comment #16)
> I believe CDR582383 is now correctly converted. I think you can go ahead and
> block CDR360874.
>

Done.

> For future requests to clean up garbled CT.gov protocol duplicate cases, it
> would probably be easier to avoid confusion, particularly when the complete set
> of instructions has to be merged from separate comments as the issue
> progresses, if a separate Bugzilla task were created for each set of cases
> which need to be handled exactly the same way (this issue had a mixture of
> various conditions which had to be dealt with differently, and I got hopelessly
> lost more than once). If it's not easy to tell which cases represent the same
> condition, even though it seems cumbersome, it would be very helpful if a
> separate task were created for each trial. These problems are complicated
> enough even when we don't bundle together different conditions in the same
> cleanup task.
>
> Thanks!

Sure..will do.

Issue closed! Thanks!