CDR Tickets

Attachment NCT ID SWAPS.xls has been added with description: NCT ID swaps

BZDATETIME::2011-06-23 08:03:26
BZCOMMENTOR::Bob Kline
BZCOMMENT::1

I dropped the rows for NCT00001586 and NCT00067821; they should be recreated tomorrow morning with dispositions of not yet reviewed instead of the 'duplicate' disposition they had previously. NCT00001803 has been coming in for several days but we've been skipping it, because the status value is 'Active, not recruiting' whereas the download software only picks up new trials whose status is Recruiting or Not yet recruiting. Do "Active, not recruiting" and "Not yet recruiting" mean the same thing? If so, has NLM changed their status value strings?

The rows for the other three NCT IDs have been marked as duplicates.

BZDATETIME::2011-06-23 11:38:52
BZCOMMENTOR::William Osei-Poku
BZCOMMENT::2

(In reply to comment #1)
> NCT00001803 has been coming in
> for several days but we've been skipping it, because the status value is
> 'Active, not recruiting' whereas the download software only picks up new trials
> whose status is Recruiting or Not yet recruiting. Do "Active, not recruiting"
> and "Not yet recruiting" mean the same thing? If so, has NLM changed their
> status value strings?

"Active, not recruiting" maps to PDQ's "Closed" status. That is why the program is skipping it. "Not yet recruiting" maps to PDQ's "Approved-not yet active" status.

BZDATETIME::2011-06-23 12:46:42
BZCOMMENTOR::Bob Kline
BZCOMMENT::3

Bob needs to research whether new documents will be created and prevent that if so.

BZDATETIME::2011-06-23 14:36:18
BZCOMMENTOR::Bob Kline
BZCOMMENT::4

I added the rows by hand to ensure the existing CDR documents will be used.

BZDATETIME::2011-06-27 10:26:20
BZCOMMENTOR::William Osei-Poku
BZCOMMENT::5

(In reply to comment #4)
> I added the rows by hand to ensure the existing CDR documents will be used.

I assume we can proceed with the force download of CDR0000065863 using the active # NCT00001586, right?

BZDATETIME::2011-06-27 10:34:23
BZCOMMENTOR::Bob Kline
BZCOMMENT::6

(In reply to comment #5)

> I assume we can proceed with the force download of CDR0000065863 using the
> active # NCT00001586, right?

I assumed that wouldn't be necessary, but I see that the download job undid the work I performed on Thursday, marking the row for NCT00001586 as a duplicate again. Let me investigate and find out why and see if I can circumvent whatever's going on to get the result we want. I must say, this import relationship with NLM has grown into a Hydra!

BZDATETIME::2011-06-27 10:47:05
BZCOMMENTOR::Bob Kline
BZCOMMENT::7

(In reply to comment #6)
> (In reply to comment #5)
>
> > I assume we can proceed with the force download of CDR0000065863 using the
> > active # NCT00001586, right?
>
> I assumed that wouldn't be necessary, but I see that the download job undid the
> work I performed on Thursday, marking the row for NCT00001586 as a duplicate
> again. Let me investigate and find out why and see if I can circumvent
> whatever's going on to get the result we want. I must say, this import
> relationship with NLM has grown into a Hydra!

Aha! This is the same problem we ran into back in January:

http://verdi.nci.nih.gov/tracker/show_bug.cgi?id=4975#c5

> 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?

See also your reply in

http://verdi.nci.nih.gov/tracker/show_bug.cgi?id=4975#c6

How would you like me to proceed? Should we discuss this at the status meeting on Thursday?

BZDATETIME::2011-06-27 11:04:24
BZCOMMENTOR::William Osei-Poku
BZCOMMENT::8

(In reply to comment #7)
> > 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?
>
> See also your reply in
>
> http://verdi.nci.nih.gov/tracker/show_bug.cgi?id=4975#c6
>
> How would you like me to proceed? Should we discuss this at the status meeting
> on Thursday?

Yes. Let's discuss this on Thursday but my preference at this point is #4. Hopefully, you can re-use the re-written software in case we get similar situations in the future. On the other hand, we can review the list Lakshmi provided to see if the rules still apply.

BZDATETIME::2011-07-14 20:10:58
BZCOMMENTOR::William Osei-Poku
BZCOMMENT::9

Please proceed to remove NCT00001586 from the duplicates table as discussed in today's meeting.

BZDATETIME::2011-07-18 15:13:20
BZCOMMENTOR::Bob Kline
BZCOMMENT::10

(In reply to comment #9)
> Please proceed to remove NCT00001586 from the duplicates table as discussed in
> today's meeting.

Done. I repopulated the ctgov_import row. Let's see what happens tomorrow morning.

BZDATETIME::2011-07-20 10:10:47
BZCOMMENTOR::Bob Kline
BZCOMMENT::11

I checked the ctgov_import table and NCT00001586 was imported as CDR65863 as you requested.

BZDATETIME::2011-08-03 20:18:53
BZCOMMENTOR::William Osei-Poku
BZCOMMENT::12

(In reply to comment #11)
> I checked the ctgov_import table and NCT00001586 was imported as CDR65863 as
> you requested.

Verified on Bach. Closing issue. Thank you!