CDR Tickets

Issue Number 3096
Summary CTGovProtocol Vendor Filter Changes
Created 2010-02-24 16:04:07
Issue Type Improvement
Submitted By Englisch, Volker (NIH/NCI) [C]
Assigned To Englisch, Volker (NIH/NCI) [C]
Status Closed
Resolved 2010-05-13 11:04:32
Resolution Fixed
Path /home/bkline/backups/jira/ocecdr/issue.107424
Description

BZISSUE::4772
BZDATETIME::2010-02-24 16:04:07
BZCREATOR::Volker Englisch
BZASSIGNEE::Volker Englisch
BZQACONTACT::William Osei-Poku

As a follow-up of OCECDR-2992 we want to use the new function that allows us to deduplicate protocol IDs.
The function should be implemented in order to remove duplicate protocol IDs. With this enhancement a secondary ID that already exists as an NCT-ID or a primary ID will be dropped from the output.

A sample of protocols with duplicates on BACH are
CDR0000528912 (DBCG07MRBRCA is duplicated)
CDR0000588143 (U01-CA-116892-03 is duplicated)

Comment entered 2010-02-25 13:57:23 by Englisch, Volker (NIH/NCI) [C]

BZDATETIME::2010-02-25 13:57:23
BZCOMMENTOR::Volker Englisch
BZCOMMENT::1

The following filter has been modified:
CDR349693 - Vendor Filter: CTGovProtocol

The changes implemented to the filter are such that prior to adding the element
SecondaryID
we're using the dedup function in order to ensure that the SecondaryID text hasn't already been displayed as either the NCTID or the OrgStudyID.

The test job on FRANCK found that with this change we're able to remove 293 duplicates from 204 protocols.

While I was looking at the results I came across two issues I'd like to mention:
a) I've noticed that there exist several InScopeProtocols for which a
duplicated protocol ID is being displayed. (i.e. CDR633506 - COL-0613)
Should we be using the new dedup function for InScopeProtocols as well?

b) When I discussed this issue with Alan we only discussed deduplicating
the SecondaryID element. However, this does not include the protocol IDs
from protocols that got transferred and may have additional IDs
included in the PDQAdmin block.
Should we include those additional PDQ protocol IDs as SecondaryIDs for
the CTGovProtocols as well?

c) This is not directly related to the deduplication of the IDs but I noticed
that some of the protocols contain information in the SecondaryID field
that's not really appropriate. For example, there are protocols listing
the grant number in the protocol field or the IRB number as is done in
CDR643723 - U54RR024347.

Lakshmi: I will include the "PDQ protocols IDs" (issue b) for now but will
not do anything at this point regarding issue (a).

Comment entered 2010-03-02 20:53:46 by Englisch, Volker (NIH/NCI) [C]

BZDATETIME::2010-03-02 20:53:46
BZCOMMENTOR::Volker Englisch
BZCOMMENT::2

This issue is on hold.

Comment entered 2010-03-18 18:55:30 by Englisch, Volker (NIH/NCI) [C]

BZDATETIME::2010-03-18 18:55:30
BZCOMMENTOR::Volker Englisch
BZCOMMENT::3

(In reply to comment #2)
> This issue is on hold.

Please ignore the previous comment. That was meant to go on a different issue.

Comment entered 2010-03-29 18:13:43 by Englisch, Volker (NIH/NCI) [C]

BZDATETIME::2010-03-29 18:13:43
BZCOMMENTOR::Volker Englisch
BZCOMMENT::4

I ran a diff report with the changes implemented as listed in Comment #1 (b) and identified about 1,500 changes for SecondaryID elements. This is a combination of added IDs due to the inclusion of the PDQAdmin block data and deduping the protocol IDs.

Should I run a CTGovProtocol-Export and load it to the GatekeeperGK server for review?

Comment entered 2010-04-08 11:48:52 by Englisch, Volker (NIH/NCI) [C]

BZDATETIME::2010-04-08 11:48:52
BZCOMMENTOR::Volker Englisch
BZCOMMENT::5

I ran a publishing job on FRANCK and loaded the data to
http://wwwGK.cancer.gov/

All of the protocols that I've seen with a duplicate name where InScopeProtocol documents, not CTGovProtocols. The two protocols that are listed in the bug description, however, are now displaying with the duplicates removed.

This is ready for review on FRANCK.

Comment entered 2010-04-28 14:36:42 by Englisch, Volker (NIH/NCI) [C]

BZDATETIME::2010-04-28 14:36:42
BZCOMMENTOR::Volker Englisch
BZCOMMENT::6

Are we ready to promote this to production or does it still need to get reviewed?

Comment entered 2010-05-12 10:43:12 by Osei-Poku, William (NIH/NCI) [C]

BZDATETIME::2010-05-12 10:43:12
BZCOMMENTOR::William Osei-Poku
BZCOMMENT::7

(In reply to comment #6)
> Are we ready to promote this to production or does it still need to get
> reviewed?

Verified. Please promote to Bach.
So when you promote to Bach, Pub preview on Bach should also remove the dup id, right?

Comment entered 2010-05-12 10:48:22 by Englisch, Volker (NIH/NCI) [C]

BZDATETIME::2010-05-12 10:48:22
BZCOMMENTOR::Volker Englisch
BZCOMMENT::8

(In reply to comment #7)
> Pub preview on Bach should also remove the dup id, right?

Yes, that's true for CTGovProtocols.

Comment entered 2010-05-13 11:01:09 by Englisch, Volker (NIH/NCI) [C]

BZDATETIME::2010-05-13 11:01:09
BZCOMMENTOR::Volker Englisch
BZCOMMENT::9

The following filter has been copied to FRANCK and BACH:
CDR349693 - R9615: Vendor Filter: CTGovProtocol

Please verify on BACH and close this bug.

Comment entered 2010-05-13 11:04:32 by Osei-Poku, William (NIH/NCI) [C]

BZDATETIME::2010-05-13 11:04:32
BZCOMMENTOR::William Osei-Poku
BZCOMMENT::10

(In reply to comment #9)
> The following filter has been copied to FRANCK and BACH:
> CDR349693 - R9615: Vendor Filter: CTGovProtocol
>
> Please verify on BACH and close this bug.

Verified on Bach. Issue closed.

Elapsed: 0:00:00.000594