CDR Tickets

BZDATETIME::2010-05-07 11:53:45
BZCOMMENTOR::Volker Englisch
BZCOMMENT::1

(In reply to comment #0)
> 2. Transferred protocols not received from NLM

I am just wondering how this report is different from the ad-hoc report
'Transfer Protocols without Transfer Date (CTGov)'
which we just finalized?

BZDATETIME::2010-05-07 12:27:36
BZCOMMENTOR::Kim Eckley
BZCOMMENT::2

(In reply to comment #0)
> We want these queries to run as nightly scheduled email reports that go out to
> specified users:
> 1. nyu@icfi.com
> 2. jmorris@icfi.com
> 3. wosei-poku@icfi.com
> 4. Kimberly.a.eckley@lmco.com
> 5. Andrea.jackson@lmco.com

Removing myself. List of users the email should be sent to:

1. nyu@icfi.com
2. jmorris@icfi.com
3. wosei-poku@icfi.com
4. andrea.jackson@lmco.com

BZDATETIME::2010-05-07 12:31:10
BZCOMMENTOR::William Osei-Poku
BZCOMMENT::3

(In reply to comment #1)
> (In reply to comment #0)
> > 2. Transferred protocols not received from NLM
>
> I am just wondering how this report is different from the ad-hoc report
> 'Transfer Protocols without Transfer Date (CTGov)'
> which we just finalized?

Transferred protocols not received from NLM

This query provides a list of trials that have been marked to be transferred but failed to be converted because they did not meet our criteria for importation of trials from CTGov. We use this report to investigate why they were not converted.

Transfer Protocols without Transfer Date (CTGov)

We use this query to identify CTgov trials (converted) that have the transfer blocks but no transfer dates. This query provides a list of all CTgov trials (converted) that have the transfer block but no transfer date. We use this report to identify transfer trials that we have not yet received confirmation from CIAT –Lockheed that they have been transferred in the PRS system.

New list of users:

1. nyu@icfi.com
2. jmorris@icfi.com
3. wosei-poku@icfi.com
4. Andrea.jackson@lmco.com
5. lhoward3@icfi.com

BZDATETIME::2010-05-07 13:32:05
BZCOMMENTOR::William Osei-Poku
BZCOMMENT::4

Please, also indicate in the report if a trial is blocked from publication.

BZDATETIME::2010-05-10 09:58:44
BZCOMMENTOR::Bob Kline
BZCOMMENT::5

(In reply to comment #0)

> iii. NCT ID of the on duplicate report

What's an "on duplicate" report?

> So I think it will be good to run this report
> after the download program has completed.

So, send this out right before the import program is run?

> Protocols should be reported only once for both reports. The reports should
> not be cumulative.

Is this wise? If the NIH mail hub eats one of these reports (and we know that service is unpredictable), you'd never see the information it contained.

BZDATETIME::2010-05-10 14:04:43
BZCOMMENTOR::William Osei-Poku
BZCOMMENT::6

(In reply to comment #5)
> (In reply to comment #0)
>
> > iii. NCT ID of the on duplicate report
>
> What's an "on duplicate" report?
>

Sorry, it should have read "iii. NCT ID on the duplicate report"
This is in reference to the "ClinicalTrials.gov Duplicate Trials Report". The second column of the report is the NCTID column. That was what I was referring to.

> > So I think it will be good to run this report
> > after the download program has completed.
>
> So, send this out right before the import program is run?
>

I am suggesting that the report should run after the conversion of documents that have been marked for transfer for a particular day. I think this will avoid the situation where documents will be reported on the report only because their conversion had not taken place yet. That is the current behavior of the 'Transferred trials not received from NLM" query.

> > Protocols should be reported only once for both reports. The reports should
> > not be cumulative.
>
> Is this wise? If the NIH mail hub eats one of these reports (and we know that
> service is unpredictable), you'd never see the information it contained.

If it has to be cumulative, it should be grouped or organized by dates. That is, the date a trial first shows up on the list.

(The problem we have encountered with cumulative reports/queries is that, users also need to maintain a separate list to determine what had previously been researched. This is especially true where it is not in every case that a trial will drop off a report.)

BZDATETIME::2010-05-11 10:49:35
BZCOMMENTOR::Bob Kline
BZCOMMENT::7

(In reply to comment #6)

> If it has to be cumulative, it should be grouped or organized by dates. That
> is, the date a trial first shows up on the list.

You're using the singular here, but there are actually two reports, and your original requests said "[p]rotocols should be reported only once for both reports" (rather than "once for each report"). If a protocol shows up on one of the reports and then shows up on the other a week later, which date controls the sorting? How about if it shows up on report A on June 1, then is dropped from that report and appears on report B on June 15, then is dropped from report B and appears again on report A on June 30: which of these three dates would be used? Is it possible for a protocol to be on both reports at the same time?

BZDATETIME::2010-05-11 12:23:10
BZCOMMENTOR::William Osei-Poku
BZCOMMENT::8

(In reply to comment #7)
> (In reply to comment #6)
>
> > If it has to be cumulative, it should be grouped or organized by dates. That
> > is, the date a trial first shows up on the list.
>
> You're using the singular here, but there are actually two reports, and your
> original requests said "[p]rotocols should be reported only once for both
> reports" (rather than "once for each report"). If a protocol shows up on one
> of the reports and then shows up on the other a week later, which date controls
> the sorting? How about if it shows up on report A on June 1, then is dropped
> from that report and appears on report B on June 15, then is dropped from
> report B and appears again on report A on June 30: which of these three dates
> would be used? Is it possible for a protocol to be on both reports at the same
> time?

It looks like combining the two reports in one email may turn out to be complicated and probably confusing to users. Please, let's stick with the original idea of having two separate reports just like we have it in the ad hoc query interface. So in this case, we will have two separate emails - one for each ad hoc query.

BZDATETIME::2010-05-12 12:35:41
BZCOMMENTOR::Bob Kline
BZCOMMENT::9

(In reply to comment #8)

> It looks like combining the two reports in one email may turn out to be
> complicated and probably confusing to users. Please, let's stick with the
> original idea of having two separate reports just like we have it in the ad hoc
> query interface. So in this case, we will have two separate emails - one for
> each ad hoc query.

Having two separate email messages doesn't eliminate the need to answer the questions I asked in comment #7. For example, if a trial shows up on one list on June 1, then moves to the other list on June 8, then moves back to the first list on June 15: do we use June 1 or June 15 for determining the sort position for the trial on that list? Please address all of my questions in that comment.

Also, please explain why it would be confusing to send a single email message if each of the two lists appears separately in the message and is clearly labeled.

BZDATETIME::2010-05-12 16:03:48
BZCOMMENTOR::William Osei-Poku
BZCOMMENT::10

(In reply to comment #7)
> (In reply to comment #6)
>
> > If it has to be cumulative, it should be grouped or organized by dates. That
> > is, the date a trial first shows up on the list.
>
> You're using the singular here, but there are actually two reports, and your
> original requests said "[p]rotocols should be reported only once for both
> reports" (rather than "once for each report").
>If a protocol shows up on one
> of the reports and then shows up on the other a week later, which date controls
> the sorting?

Please use the more recent date.

>How about if it shows up on report A on June 1, then is dropped
> from that report and appears on report B on June 15, then is dropped from
> report B and appears again on report A on June 30: which of these three dates
> would be used?

Use the more recent date.

>Is it possible for a protocol to be on both reports at the same
> time?

Yes. It is possible. It is possible for a trial to not meet the criteria for importing from CTGov and also be on the ctgov duplicate list.

(In reply to comment #9)

> Also, please explain why it would be confusing to send a single email message
> if each of the two lists appears separately in the message and is clearly
> labeled.

> labeled.

The fact that one trial can show up under one label and at another time, it will show up under the other label (or even show up under both labels at the same time) may confuse one to think that is has already been taken of, when in fact it was only taken care of under different circumstance and not the other.

Identifying the protocols on these reports is just the first step in fixing the problem. The next steps can be complex and also confusing. My goal is not to add more complexity to the situation, no matter how small it is.

BZDATETIME::2010-05-21 12:55:05
BZCOMMENTOR::Bob Kline
BZCOMMENT::11

I'm not sure the issue reflects the most recent decision for how this task should be handled. Didn't we go back to "don't include a trial more than once on the report but make it possible to get a cumulative list on demand" (or something like that)? If the previous comments aren't an up-to-date reflection of the requirements, please update them to match what we're supposed to do.

BZDATETIME::2010-05-21 13:02:56
BZCOMMENTOR::William Osei-Poku
BZCOMMENT::12

(In reply to comment #11)
> I'm not sure the issue reflects the most recent decision for how this task
> should be handled. Didn't we go back to "don't include a trial more than once
> on the report but make it possible to get a cumulative list on demand" (or
> something like that)? If the previous comments aren't an up-to-date reflection
> of the requirements, please update them to match what we're supposed to do.

That is correct. This is what I remember:

1. Don't include a trial more than once.
2. Make it possible to get a cumulative list on demand.
3. Also, it is OK to combine the two queries into one scheduled email.

BZDATETIME::2010-06-01 16:20:56
BZCOMMENTOR::Bob Kline
BZCOMMENT::13

I have implemented this on Mahler. Differences from the report which will be installed on the production server:

1. The recipient list is the set of those associated with this issue
2. The data is from Mahler
3. I'm not yet suppressing re-reporting a trial (for testing more than once)

List for myself of what's involved (so I won't forget anything when this is promoted):

• Add "REPORT 4825" action and group

• Populate group with individuals listed in comment #3

• Add two new columns to ctgov_import table

• Enable code to populate the new columns

• Add script to scheduler on Bach

Shortly after I have posted this comment I'll send out the first test report.

BZDATETIME::2010-06-03 10:45:20
BZCOMMENTOR::William Osei-Poku
BZCOMMENT::14

(In reply to comment #13)
> I have implemented this on Mahler. Differences from the report which will be
> installed on the production server:
>
> 1. The recipient list is the set of those associated with this issue
> 2. The data is from Mahler
> 3. I'm not yet suppressing re-reporting a trial (for testing more than once)
>
> List for myself of what's involved (so I won't forget anything when this is
> promoted):
>
> * Add "REPORT 4825" action and group
> * Populate group with individuals listed in comment #3
> * Add two new columns to ctgov_import table
> * Enable code to populate the new columns
> * Add script to scheduler on Bach
>
> Shortly after I have posted this comment I'll send out the first test report.

Reviewed the email. Looks good.
You wrote:
"....... THE PRODUCTION VERSION WILL SUPPRESS MULTIPLE REPORTS FOR A SINGLE TRIAL".
This will not prevent a trial from being reported under each label for a given day, right? That is, a trial that is marked as a duplicate and also not received from NLM can be reported on the same day, once for each of the two labels?

BZDATETIME::2010-06-03 10:54:13
BZCOMMENTOR::Bob Kline
BZCOMMENT::15

(In reply to comment #14)

> ... a trial that is marked as a duplicate and also not received from
> NLM can be reported on the same day, once for each of the two labels?

I believe there was at least one example of this on the test report.

BZDATETIME::2010-06-03 11:07:26
BZCOMMENTOR::William Osei-Poku
BZCOMMENT::16

(In reply to comment #15)
> (In reply to comment #14)
>
> > ... a trial that is marked as a duplicate and also not received from
> > NLM can be reported on the same day, once for each of the two labels?
>
> I believe there was at least one example of this on the test report.

Yes - CDR0000450771 NCT00293306

Because you had said ""....... THE PRODUCTION VERSION WILL SUPPRESS MULTIPLE REPORTS FOR A SINGLE TRIAL".", I just wanted a clarification that trials in the above example won't be affected.

BZDATETIME::2010-06-07 10:47:56
BZCOMMENTOR::William Osei-Poku
BZCOMMENT::17

Please promote to Bach.

BZDATETIME::2010-06-08 10:22:03
BZCOMMENTOR::Bob Kline
BZCOMMENT::18

Promoted to Bach.

BZDATETIME::2010-06-09 09:43:47
BZCOMMENTOR::William Osei-Poku
BZCOMMENT::19

(In reply to comment #18)
> Promoted to Bach.

Verified. Issue closed!