| Issue Number | 3071 |
|---|---|
| Summary | [CTgov] download skipping trials that used to belong to PDQ |
| Created | 2010-01-29 09:54:15 |
| Issue Type | Bug |
| Submitted By | Kline, Bob (NIH/NCI) [C] |
| Assigned To | Kline, Bob (NIH/NCI) [C] |
| Status | Closed |
| Resolved | 2010-02-01 12:59:53 |
| Resolution | Fixed |
| Path | /home/bkline/backups/jira/ocecdr/issue.107399 |
BZISSUE::4747
BZDATETIME::2010-01-29 09:54:15
BZCREATOR::Bob Kline
BZASSIGNEE::Bob Kline
BZQACONTACT::Lakshmi Grama
We need to modify the CT.gov download program so that it ignores the rule to skip documents which used to belong to PDQ but have been transferred. We decided to do this by checking the document type of the CWD for the CDR ID in NLM's org_study_id element. Here's a fuller explanation from an email message sent before this issue was created:
============================== snip
======================================
It's beginning to look as if the problem has hit us before, but no one
noticed until now. The download program skips over documents which we
get from NLM but which it determines really belong to us. It has always
recognized these documents by noticing that NLM sends a CDR ID in the
org_study_id element. When we started transferring protocols we changed
the logic so that if the document represented by the CDR contained
transfer information we would no longer consider it as a protocol to be
skipped. When we switched to importing CTGovProtocol documents "in
place" (over top of the original InScopeProtocol document, using the
same CDR ID) the download program was no longer able to find the
transfer block. I can think of two ways around this problem. The first
would be to fall back on looking for the transfer information in the
CTGovProtocol if we can't find it in the query term table using the
InScopeProtocol path information. The second would be to use the fact
that the CDR ID points to a document the CWD for which is a
CTGovProtocol as evidence that the trial no longer belongs to us.
Does this sound like a reasonable analysis of the problem? Does either of you see any reason not to use the second solution to the problem (which would be more straightforward)?
If you agree, I propose that we test by running the download/import
on Franck using the existing software, then run it again with a modified
version of the download program which incorporates the one of the
changes identified above.
============================== snip
======================================
We decided on the second approach.
BZDATETIME::2010-01-29 09:56:04
BZCOMMENTOR::Bob Kline
BZCOMMENT::1
I've implemented the change and I'm running a test on Franck.
BZDATETIME::2010-01-29 13:56:40
BZCOMMENTOR::Bob Kline
BZCOMMENT::2
There was a problem with the first attempt. I've corrected it and am running the test again.
BZDATETIME::2010-01-29 14:59:00
BZCOMMENTOR::Bob Kline
BZCOMMENT::3
OK, now you can test. I checked and the protocol which sparked this issue got updated, so I'm expecting that they'll all flush through.
BZDATETIME::2010-01-29 16:31:30
BZCOMMENTOR::William Osei-Poku
BZCOMMENT::4
(In reply to comment #3)
> OK, now you can test. I checked and the protocol which sparked this
issue got
> updated, so I'm expecting that they'll all flush through.
I looked at several of the trials (on Franck) that were downloaded and also compared with some on CTGov and other trials that were downloaded today on Bach and have no reason to believe that the download is not working correctly.
I think it is OK to promote it to Bach.
BZDATETIME::2010-01-29 17:43:42
BZCOMMENTOR::Bob Kline
BZCOMMENT::5
Promoted to Bach. Should kick in tomorrow morning.
BZDATETIME::2010-02-01 12:59:53
BZCOMMENTOR::William Osei-Poku
BZCOMMENT::6
(In reply to comment #5)
> Promoted to Bach. Should kick in tomorrow morning.
Verified on Bach. We hot-fixed the ECOG-E5103. It is showing the correct status on cancer.gov - as active
This issue is now closed. Thank you!
Elapsed: 0:00:00.000444