CDR Tickets

BZDATETIME::2010-03-10 18:01:04
BZCOMMENTOR::Volker Englisch
BZCOMMENT::1

(In reply to comment #0)
> 1.We want the ability to run the report for individual summaries either by CDR
> ID or by title. (This is in addition to running the report for all summaries.)

Do you still want to select the protocol status when a single summary is selected or display all links?

> 2.We also want to add a date range in two situations:
>
> A. Report summaries, whose referenced protocols have changed status within a
> period of time– For example, if the status of NCCTG-55885 which is referenced
> in Summary CDR ID 585822 has changed from Active to Closed in the last 30
> days, report it.

You really don't care about the direction of the change itself (Active --> Closed, Temp Closed – Closed, etc.) but only about the fact that the status changed within the given time period, right?

> 3. Add ability to generate report in MS Excel format.

Does this replace the current HTML report or are you looking for a second option to being able to also create Excel output?

> 4. Display summaries in chronological order - display protocols (IDs) from the
> top of the summary down to the bottom. Currently the report does not follow a
> chronological order within a summary.

What do you expect the summaries to be sorted by? Is that the DateLastModified?
Currently the report is sorted by protocol status, then CDR-ID.
The new sorting will replace this sort-order, right?

> 5.Display subsection titles in the report. That is, create a new column that
> lists the subsection titles where the protocol is referenced.

This is already implemented or I don't understand the request of displaying the subsection titles.

BZDATETIME::2010-03-10 21:13:43
BZCOMMENTOR::William Osei-Poku
BZCOMMENT::2

(In reply to comment #1)
> (In reply to comment #0)
> > 1.We want the ability to run the report for individual summaries either by CDR
> > ID or by title. (This is in addition to running the report for all summaries.)
>
> Do you still want to select the protocol status when a single summary is
> selected or display all links?
>

Yes and actually the option to select one status or all statuses will be good.

>
> > 2.We also want to add a date range in two situations:
> >
> > A. Report summaries, whose referenced protocols have changed status within a
> > period of time– For example, if the status of NCCTG-55885 which is referenced
> > in Summary CDR ID 585822 has changed from Active to Closed in the last 30
> > days, report it.
>
> You really don't care about the direction of the change itself (Active -->
> Closed, Temp Closed – Closed, etc.) but only about the fact that the status
> changed within the given time period, right?
>

We care about it but that will mean we need to have options for every possible status change direction. This is likely to make the report confusing (unless there is a way to make it simpler). I think it would be good to have the ability to choose to display summaries, whose referenced protocol status have changed to one status or not. In that case, the options available to us will be the usual protocol statuses.

>
> > 3. Add ability to generate report in MS Excel format.
>
> Does this replace the current HTML report or are you looking for a second
> option to being able to also create Excel output?
>
We are looking for a second one in addition to the current HTML
>
> > 4. Display summaries in chronological order - display protocols (IDs) from the
> > top of the summary down to the bottom. Currently the report does not follow a
> > chronological order within a summary.
>
> What do you expect the summaries to be sorted by? Is that the
> DateLastModified?
> Currently the report is sorted by protocol status, then CDR-ID.
> The new sorting will replace this sort-order, right?
>

Can you sort it by the way the protocols appear in the summary? That is, if RTOG-0000 is referenced in the first paragraph of the summary and SWOG-0000 is referenced in the last paragraph, RTOG-0000 should come first followed by SWOG-0000 (assuming there are no other protocols referenced between the two mentioned above).
>
> > 5.Display subsection titles in the report. That is, create a new column that
> > lists the subsection titles where the protocol is referenced.
>
> This is already implemented or I don't understand the request of displaying the
> subsection titles.

You're right. This is already implemented. It is the same thing we are looking for. Thank you

BZDATETIME::2010-04-05 15:36:11
BZCOMMENTOR::Volker Englisch
BZCOMMENT::3

(In reply to comment #0)
> 1.We want the ability to run the report for individual summaries either by CDR
> ID or by title. (This is in addition to running the report for all summaries.)

I have completed this part.

> 2.We also want to add a date range in two situations:

I am still not clear on these two date range conditions (see questions below):

> A. Report summaries, whose referenced protocols have changed status within a
> period of time

How would you identify the date for a protocol status change?

> B. Report summaries that have not been reviewed (ProtocolRef LastReviewed
> date) in the last 30 days, for example.

I don't understand why you are listing the "ProtocolRef --> LastReviewed" date here when you're interested in Summaries not reviewed?
As with option (A) what would identify a reviewed summary and which data element should be checked against the specified date range?

> 6.Include a column for the comments and another one for the date. That is, in
> addition to existing columns.

I have completed this part.

BZDATETIME::2010-04-05 16:01:16
BZCOMMENTOR::William Osei-Poku
BZCOMMENT::4

(In reply to comment #3)

> > A. Report summaries, whose referenced protocols have changed status within a
> > period of time
>
> How would you identify the date for a protocol status change?
>
Please take a look at the Protocol Status Change Report which is run by a user supplied date range: CIAT/OCCM Staff > Reports > Protocols > Protocol Status Change Report. That might be more helpful than me trying to explain in non technical terms :-). Let me know that is not enough and I will do my best 

> > B. Report summaries that have not been reviewed (ProtocolRef LastReviewed
> > date) in the last 30 days, for example.
>
> I don't understand why you are listing the "ProtocolRef --> LastReviewed" date
> here when you're interested in Summaries not reviewed?
> As with option (A) what would identify a reviewed summary and which data
> element should be checked against the specified date range?
>

We are not only interested in summaries that have not been reviewed. We are interested in summaries that have not been reviewed in a given period of time and I supplied the (ProtocolRef --> LastReviewed) only to serve as what you may use to determine when a summary/ProtocolRef was last reviewed or whether it has not been reviewed at all.

>
> > 6.Include a column for the comments and another one for the date. That is, in
> > addition to existing columns.
>
> I have completed this part.

BZDATETIME::2010-04-05 18:41:22
BZCOMMENTOR::Volker Englisch
BZCOMMENT::5

Status Update for sub-tasks currently finished on MAHLER:

[X] Ability to run report for summaries by CDR-ID or summary title
[ ] Specify date range for linked protocol status change
[X] Specify date range for ProtocolLink/Ref LastReviewed attribute
[ ] Ability to export report in Excel format
[X] Display ProtocolLink/Ref entries in document order (not sorted by status)
[X] Display subsection titles in the report
[X] Include columns for the ProtocolLink/Ref comment and LastReviewed attribute

BZDATETIME::2010-04-07 13:01:49
BZCOMMENTOR::Volker Englisch
BZCOMMENT::6

The report can now be exported to Excel.

Status Update for sub-tasks currently finished on MAHLER:

[X] Ability to run report for summaries by CDR-ID or summary title
[ ] Specify date range for linked protocol status change
[X] Specify date range for ProtocolLink/Ref LastReviewed attribute
[X] Ability to export report in Excel format
[X] Display ProtocolLink/Ref entries in document order (not sorted by status)
[X] Display subsection titles in the report
[X] Include columns for the ProtocolLink/Ref comment and LastReviewed
attribute

BZDATETIME::2010-04-07 19:07:53
BZCOMMENTOR::Volker Englisch
BZCOMMENT::7

(In reply to comment #4)
> Please take a look at the Protocol Status Change Report which is run by a user
> supplied date range: CIAT/OCCM Staff > Reports > Protocols > Protocol Status
> Change Report.

First of all, this Protocol Status Change report doesn't really look a protocol status change but a LeadOrg status change and secondly, this report only looks at InScopeProtocols.
Is this what you are interested in: the lead org status change of InScopeProtocols?

BZDATETIME::2010-04-08 09:58:06
BZCOMMENTOR::William Osei-Poku
BZCOMMENT::8

(In reply to comment #7)
> (In reply to comment #4)
> > Please take a look at the Protocol Status Change Report which is run by a user
> > supplied date range: CIAT/OCCM Staff > Reports > Protocols > Protocol Status
> > Change Report.
>
> First of all, this Protocol Status Change report doesn't really look a protocol
> status change but a LeadOrg status change and secondly, this report only looks
> at InScopeProtocols.
> Is this what you are interested in: the lead org status change of
> InScopeProtocols?

We are interested in the Overall status of the CTGovProtocol document and the CurrentProtocolStatus of the InScope protocol. For InScope documents which have a single lead org, the value of the StatusName element within the CurrentOrgStatus block is typically the same as the value of the CurrentProtocolStatus. For Multiple Lead Org protocols, the CurrentProtocolStatus is calculated by an algorithm so it could be different from the StatusName value.

The summary document can reference an InscopeProtocol document and/or a CTGovProtocol document.

Getting back to your earlier question in comment #3. I think one way to determine the date of a status change will be to look at the date that the document was made publishable following the status change. So that if a protocol document has changed status but has not been made publishable, the report can skip it until there is a publishable version (assuming the status is not changed back to the original status before it was made publishable).

I am suggesting this because users will be looking at this report to identify referenced protocols (typically those that have been published on cancer.gov) that have changed status since they were referenced in the summary. The text in these summaries will not read correctly because they will be referring to an Active protocol, for example, when in fact the protocol has closed. However, if the protocol is made publishable after the status change, then the status change takes effect on cancer.gov. In that case, we want to be able to retrieve this in the report and make the appropriate changes.

BZDATETIME::2010-04-08 10:43:31
BZCOMMENTOR::Volker Englisch
BZCOMMENT::9

(In reply to comment #8)
> I think one way to determine the date of a status change will be to
> look at the date that the document was made publishable following
> the status change.

I'm including an email from Bob on how he explained the process of finding a status change date for protocols:

---Original Message---
From: Kline, Robert (NCI)
Sent: Monday, April 05, 2010 1:31 PM
To: Englisch, Volker (NIH/NCI) [C]
Cc: Grama, Lakshmi (NIH/NCI) [E]; Osei-Poku, William
Subject: Re: Protocol Status

Englisch, Volker (NIH/NCI) [C] wrote:
> Bob,
>
> I hope this is an easy question (with an easy answer):
> If I were the date that a protocol last changed its status how would
> you find me?
>
> I see that some protocols contain a ProtocolAmendmentInformation block
> with a ChangeType="Status" and a date associated with it but I'm not sure
> this is what William is looking for when he asks for the Protocol Change
> Date of a ProtocolRef/Link in a summary.
>
>

I assume you're talking about InScopeProtocol documents (correct me if
I'm wrong). There are two ways to find that date, neither likely to
match your definition of "easy." One is to load and parse versions of
the document walking backwards in time until you find a version with a
CurrentProtocolStatus whose value is different from the value in the
latest version of the document. The date you're looking for is the date
of the version immediately following the version you just parsed. A
special case is represented by the situation in which the current
working copy of the document has a value different from that in the
latest version of the document. In such a case you can't really tell
when the value changed, because it might have happened as a result any
of an unlimited number of save events, and in fact it might even have
gone back and forth in a series of unversioned saves, with no way to
tell what the value was except for the most recent of those save
events. The simplest (and not an unreasonable) way around that problem
is to ignore unversioned changes to the document altogether. Another
way around the problem is to treat a CWD with unversioned changes as the
latest in the sequence of versions for the document, ignoring any
unversion changes prior to the latest save.

The second method is to collect all of the lead org status information
and reconstruct the sequence of calculated overall protocol status
values over time. You could actually do this from the query_term table,
but it's probably simpler to just parse the document, and given the
results of my most recent benchmarks of the lxml module (which show
blazingly fast performance), that may be at least as efficient. We need
to do this often enough that I might just put a routine in cdr.py to
build the history of protocol statuses for a given protocol. Of course,
the days of glory for InScopeProtocol documents are waning quickly, so
I'm not going to bother unless you decide this is really the route you
want to pursue for this task.

I've copied Lakshmi in case I've forgotten something relevant here.

–
Bob Kline
http://www.rksystems.com
mailto:bkline@rksystems.com

BZDATETIME::2010-04-08 11:05:46
BZCOMMENTOR::Volker Englisch
BZCOMMENT::10

Let's discuss at the meeting if we should create a routine in cdr.py to get the protocol status change date as Bob has suggested.
My guess would be that the answer is probably 'Yes' since - as William mentioned - this is needed for CTGovProtocols as well.

Given the fact that this report might run a very long time since many versions of each document will have to be parsed to identify the last status change date it may make sense to pass the date range that we are interested in. We wouldn't have to parse any document if no publishable version was created during the given time frame.

BZDATETIME::2010-04-08 16:54:35
BZCOMMENTOR::Volker Englisch
BZCOMMENT::11

A decision has been made at the status meeting that rather then implementing one of the expensive options that Bob had suggested (of which the second one would not work for CTGovProtocols) we would go a different route and ad another attribute to the ProtocolLink/Ref element allowing the users to indicate the current "status type" (open/closed) which then could be used to only display ProtocolLinks/Refs for which the current status doesn't match this "status type".

My question is now the following:
Do we want to keep this issue open until that attribute has been created and possibly populated or do we want to go ahead and test this report as is without the last option and get it into production?

BZDATETIME::2010-04-08 17:03:03
BZCOMMENTOR::Bob Kline
BZCOMMENT::12

I've installed the StatusType attribute for the ProtocolRef and ProtocolLink elements on Mahler.

BZDATETIME::2010-04-08 17:13:05
BZCOMMENTOR::Volker Englisch
BZCOMMENT::13

I guess this answers my question.

(Bob, I didn't write this as a means to tell you: Do it NOW!) :-)

William, with this option we don't need to enter a date range. We probably want to be able to select a radio button something like this:

Display: ( ) All ❌ Changed Only

What do you think?

BZDATETIME::2010-04-09 12:59:40
BZCOMMENTOR::William Osei-Poku
BZCOMMENT::14

(In reply to comment #13)
> I guess this answers my question.
>
> (Bob, I didn't write this as a means to tell you: Do it NOW!) :-)
>
> William, with this option we don't need to enter a date range. We probably want
> to be able to select a radio button something like this:
>
> Display: ( ) All ❌ Changed Only
>
> What do you think?

I think limiting it by date will still be useful. Assuming there are too many status updates within a period, displaying all of them will not be helpful. I think it will help us to manage work-flow better if we can limit it to certain date ranges. If limiting it to a date range will not be easy to implement, then we can consider limiting the output to a set number of summaries provided by the user.

BZDATETIME::2010-04-09 13:16:20
BZCOMMENTOR::Bob Kline
BZCOMMENT::15

(In reply to comment #14)

> I think limiting it by date will still be useful.

The solution we adopted at yesterday's meeting does not involve storing the date the status changed.

BZDATETIME::2010-04-09 13:24:33
BZCOMMENTOR::Volker Englisch
BZCOMMENT::16

(In reply to comment #14)
> I think limiting it by date will still be useful.

What date are you now referring to?
The purpose for adding this new attribute is so that we do not have to identify the last protocol status change date which would be necessary to do and would possibly be very slow to calculate.

If you are referring to the date range for the LastReviewed date, however, that's already implemented.

> Assuming there are too many
> status updates within a period, displaying all of them will not be helpful.

If there are too many you would probably want to run the report by individual summary, which is already implemented, or by date range for the LastReviewed date.

> we can consider limiting the output to a set number of summaries provided by
> the user.

I don't see how this would give you more control than the date range you're entering for the LastReviewed date?

BZDATETIME::2010-04-09 13:36:06
BZCOMMENTOR::William Osei-Poku
BZCOMMENT::17

(In reply to comment #16)
> (In reply to comment #14)
> > I think limiting it by date will still be useful.
> What date are you now referring to?
> The purpose for adding this new attribute is so that we do not have to identify
> the last protocol status change date which would be necessary to do and would
> possibly be very slow to calculate.
> If you are referring to the date range for the LastReviewed date, however,
> that's already implemented.

Yes. I was referring to that date range. I have not yet looked at the current implementation but can you explain your question in comment #14 since we asked for only one date range? I thought you were going to replace the date range with the new display in comment #14.

BZDATETIME::2010-04-09 13:58:19
BZCOMMENTOR::William Osei-Poku
BZCOMMENT::18

(In reply to comment #12)
> I've installed the StatusType attribute for the ProtocolRef and ProtocolLink
> elements on Mahler.

Verified on Mahler. Please promote to Bach.

BZDATETIME::2010-04-09 14:20:15
BZCOMMENTOR::Volker Englisch
BZCOMMENT::19

In comment #6 I've last listed the features that you had requested and which I had already implemented. The last one missing here was the display of links based on the date range specified for a protocol change.

In comment #13 I've asked how you would like to replace this date range for protocol statuses given the new attribute implemented.

Your answer in comment #14 sounded to me that you still wanted to be able to specify a date range for the protocol status change but it seems that I did misunderstand your answer.

So, to be extra sure, I'm going to implement the option as specified in comment #13 and I'm adding another column at the end of the report listing the StatusType attribute.
If the option 'Changed only' is selected only those records will be displayed for which the current protocol status does not match the StatusType.

Did I summarize this correctly, William?

BZDATETIME::2010-04-09 15:26:14
BZCOMMENTOR::William Osei-Poku
BZCOMMENT::20

(In reply to comment #19)
> #13 and I'm adding another column at the end of the report listing the
> StatusType attribute.
> If the option 'Changed only' is selected only those records will be displayed
> for which the current protocol status does not match the StatusType.
> Did I summarize this correctly, William?

Yes. This sounds good to me. Thanks!

BZDATETIME::2010-04-09 16:40:34
BZCOMMENTOR::Bob Kline
BZCOMMENT::21

(In reply to comment #18)
> Please promote to Bach.

Done.

BZDATETIME::2010-04-12 18:12:25
BZCOMMENTOR::Volker Englisch
BZCOMMENT::22

I've implemented the last feature of selecting and displaying the protocol link based on the newly implemented StatusType attribute.

This is ready for review on MAHLER.

BZDATETIME::2010-04-13 13:06:03
BZCOMMENTOR::Volker Englisch
BZCOMMENT::23

As a follow up to the last feature implemented I just wanted to mention how the rows are being selected if only the changed protocol statuses should be listed:
If a protocol status is
'Active', 'Approved-not yet active', 'Enrolling by invitation'
and the StatusType is 'Closed' the record would be displayed.
Similarily, if a protocol status is
'Withdrawn from PDQ', 'Temporarily closed', 'Completed', 'Closed', 'Withdrawn'
and the StatusType is 'Open' the record would be displayed.

BZDATETIME::2010-04-13 15:45:24
BZCOMMENTOR::William Osei-Poku
BZCOMMENT::24

When I enter date values and leave all other options in their default selection, I get "<type 'exceptions.ValueError'>" error message.

BZDATETIME::2010-04-13 16:30:01
BZCOMMENTOR::Volker Englisch
BZCOMMENT::25

I can't confirm this. What's the format that you are entering for the date?
It should be YYYY-MM-DD and you have to enter the start date and end date.

The report currently fails because an invalid link date of '2010-03-32' has been entered.

BZDATETIME::2010-04-14 15:34:00
BZCOMMENTOR::William Osei-Poku
BZCOMMENT::26

Actually, I am putting in the right dates (I just tried it again) and got the attached error. The second page shows part of my selection criteria. I was not only testing and not particularly limiting the output for a set results. Other combinations of the selection criteria with the same dates that produced the error work fine.

Attachment Protocol links error.docx has been added with description: Protocol links error

BZDATETIME::2010-04-14 16:30:45
BZCOMMENTOR::Volker Englisch
BZCOMMENT::27

I didn't understand your 'type exceptions.ValueError' you reported.

Actually, whenever you see this type of page (with pink and violet rows) this is a Python error that needs to be reported.

This error is telling me that - as I mentioned earlier - a date in the data is listed as '2010-03-32', which is, of course, an incorrect date.
Please check the Breast Cancer summary (CDR62787) to fix this date and then try to run the report again.

BZDATETIME::2010-04-15 10:34:44
BZCOMMENTOR::William Osei-Poku
BZCOMMENT::28

(In reply to comment #27)
> I didn't understand your 'type exceptions.ValueError' you reported.
>
> Actually, whenever you see this type of page (with pink and violet rows) this
> is a Python error that needs to be reported.
>
> This error is telling me that - as I mentioned earlier - a date in the data is
> listed as '2010-03-32', which is, of course, an incorrect date.
> Please check the Breast Cancer summary (CDR62787) to fix this date and then try
> to run the report again.

Thanks. I corrected the date in the summary and it worked.

With regards to the date fields, is it possible for you to provide a calendar so that users don't have to type the dates in but only select the dates from the calendar?

BZDATETIME::2010-04-16 18:28:07
BZCOMMENTOR::Volker Englisch
BZCOMMENT::29

(In reply to comment #28)
> is it possible for you to provide a calendar

Done.

BZDATETIME::2010-04-19 12:57:15
BZCOMMENTOR::William Osei-Poku
BZCOMMENT::30

On the user interface:

1. The title of the first segment rightly says 'Enter CDR-ID or Summary Title".
Please put 'Or' between the two fields below the title.

2. For all the affected segments, when 'All ....' is selected, could you change the behaviors of the select box so that either all the options will be automatically selected or make it impossible for users to select both 'All ...' and other available options?

3. We did not ask for this initially but could you create links to the referenced protocols using the CDR IDs? A link to the Full QC report is desired.
4. When I don't select any date range, I am getting the attached python script error message. Is this also a problem with data in the summaries?
Also, is the date range required to run the report?

Attachment python error.docx has been added with description: Error message

BZDATETIME::2010-04-19 14:52:16
BZCOMMENTOR::Volker Englisch
BZCOMMENT::31

(In reply to comment #30)
> 1. The title of the first segment rightly says 'Enter CDR-ID or Summary
> Title".
> Please put 'Or' between the two fields below the title.

Done.

> 2. For all the affected segments, when 'All ....' is selected, could you
> change the behaviors of the select box

Fixed.

> 3. We did not ask for this initially but could you create links to the
> referenced protocols using the CDR IDs? A link to the Full QC report is
> desired.

Actually, this was part of the previous report. However, due to the request to modify the report to display the result in HTML as well as Excel format I had to drop the function that created the links in the HTML output.

> 4. When I don't select any date range, I am getting the attached
> python script error message.

Could you please let me know what exactly you are entering and which options you're choosing? When I run this on MAHLER without any date range I don't see the error message.
Did you maybe enter one date but not the other?

BZDATETIME::2010-04-19 15:01:47
BZCOMMENTOR::William Osei-Poku
BZCOMMENT::32

(In reply to comment #31)
> > 3. We did not ask for this initially but could you create links to the
> > referenced protocols using the CDR IDs? A link to the Full QC report is
> > desired.
>
> Actually, this was part of the previous report. However, due to the request to
> modify the report to display the result in HTML as well as Excel format I had
> to drop the function that created the links in the HTML output.
>
It is possible to have it back :-). I will ask users to see whether they are OK with this feature going away.
>
> > 4. When I don't select any date range, I am getting the attached
> > python script error message.
>
> Could you please let me know what exactly you are entering and which options
> you're choosing? When I run this on MAHLER without any date range I don't see
> the error message.
> Did you maybe enter one date but not the other?

I selected English, All English, All Status, Include All, HTML.
Those are the default selections.

BZDATETIME::2010-04-19 15:02:54
BZCOMMENTOR::William Osei-Poku
BZCOMMENT::33

(In reply to comment #32)
> (In reply to comment #31)
> > > 3. We did not ask for this initially but could you create links to the
> > > referenced protocols using the CDR IDs? A link to the Full QC report is
> > > desired.
> >
> > Actually, this was part of the previous report. However, due to the request to
> > modify the report to display the result in HTML as well as Excel format I had
> > to drop the function that created the links in the HTML output.
> >
> It is possible to have it back :-). I will ask users to see whether they are

Sorry I meant, is it possible to have it back?

BZDATETIME::2010-04-19 15:20:44
BZCOMMENTOR::Volker Englisch
BZCOMMENT::34

(In reply to comment #30)
> 4. When I don't select any date range, I am getting the attached python script
> error message.

Fixed.

BZDATETIME::2010-04-20 13:35:43
BZCOMMENTOR::William Osei-Poku
BZCOMMENT::35

I have a few more changes to be made:

1. On the report (output), please change the column name 'Status' to 'Current Protocol Status'.

2. In the 'Protocol Link/Ref' column, please make the referenced primary id of the protocol red font so that they can stand out.

3. On the form/user interface under the “Select Trial Status..” column, can you also include the status - 'Enrolling by Invitation'?

4. On the form/user interface, can you include another Date Range element under the "Exclude ProtocolLink/Ref Elements reviewed during this Date Range" segment, called "Include ProtocolLink/Ref Elements reviewed during this Date Range". So it is going to alternate with the existing Exclude one and it will retrieve documents that have been reviewed instead of the ones that have not been reviewed.

5. We want to include another Last Status value = “Completed”

BZDATETIME::2010-04-20 13:37:42
BZCOMMENTOR::William Osei-Poku
BZCOMMENT::36

(In reply to comment #23)
> As a follow up to the last feature implemented I just wanted to mention how the
> rows are being selected if only the changed protocol statuses should be listed:
> If a protocol status is
> 'Active', 'Approved-not yet active', 'Enrolling by invitation'
> and the StatusType is 'Closed' the record would be displayed.
> Similarily, if a protocol status is
> 'Withdrawn from PDQ', 'Temporarily closed', 'Completed', 'Closed',
> 'Withdrawn'
> and the StatusType is 'Open' the record would be displayed.

So it is comparing the current protocol status with the status Status type, right?

BZDATETIME::2010-04-20 13:40:28
BZCOMMENTOR::Volker Englisch
BZCOMMENT::37

Yes.

BZDATETIME::2010-04-20 13:42:28
BZCOMMENTOR::William Osei-Poku
BZCOMMENT::38

(In reply to comment #35)

> 5. We want to include another Last Status value = “Completed”

**The correct attribute is 'StatusType' and referring to your explanation in comment #23, the new StatusType='Completed' should map to the 'Completed' status and should be excluded from the list of the 'Closed' StatusType.

BZDATETIME::2010-04-28 13:30:42
BZCOMMENTOR::Volker Englisch
BZCOMMENT::39

(In reply to comment #33)
> Sorry I meant, is it possible to have it back?

Please see below under item (2)

(In reply to comment #35)
> 1. On the report (output), please change the column name 'Status' to 'Current
> Protocol Status'.

Done.

> 2. In the 'Protocol Link/Ref' column, please make the referenced primary id of
> the protocol red font so that they can stand out.

In the original report we listed the Protocol-ID as a link and in red color. This worked fine within an HTML report but not in the Excel output.
I have restored this functionality in the HTML version of the report.
For the Excel report it is currently not possible to mark up text within a table cell with a different color unless the entire text is displayed in this color. The same is true for creating links.

> 3. On the form/user interface under the “Select Trial Status..” column, can
> you also include the status - 'Enrolling by Invitation'?

Done.

> 4. On the form/user interface, can you include another Date Range element

Done.

> 5. We want to include another Last Status value = “Completed”

Before I'm implementing this change we might want to talk about it first at the meeting on Thursday. We should probably discuss why we wouldn't want to capture the true status of the protocol in this attribute rather than adding more status types?

BZDATETIME::2010-04-29 18:23:33
BZCOMMENTOR::Volker Englisch
BZCOMMENT::40

As discussed at our status meeting we will change the new attribute 'StatusType' and replace it with the attribute 'LastReviewedStatus' to capture the protocol status at the time the comment had been reviewed.

Bob: Could you please make the change to the schema when you have a minute?

BZDATETIME::2010-04-29 22:40:40
BZCOMMENTOR::Bob Kline
BZCOMMENT::41

(In reply to comment #40)

> Bob: Could you please make the change to the schema when you have a minute?

Done.

BZDATETIME::2010-05-05 15:25:58
BZCOMMENTOR::Volker Englisch
BZCOMMENT::42

(In reply to comment #40)
> Bob: Could you please make the change to the schema when you have a minute?

I was wondering: Wouldn't it make sense to provide the users a drop-down list to populate the status values?

BZDATETIME::2010-05-05 16:00:13
BZCOMMENTOR::Bob Kline
BZCOMMENT::43

Can't do that for attributes which have spaces without creating a custom dialog box, and if we're going to go to that much trouble, why not a macro to calculate and set the value automatically?

BZDATETIME::2010-05-05 16:26:06
BZCOMMENTOR::Volker Englisch
BZCOMMENT::44

Oh, I forgot those nasty little spaces.

In that case I better change my code to case insensitive comparison.

BZDATETIME::2010-05-05 16:32:04
BZCOMMENTOR::Volker Englisch
BZCOMMENT::45

The report is ready for review on MAHLER.

BZDATETIME::2010-05-10 12:41:24
BZCOMMENTOR::William Osei-Poku
BZCOMMENT::46

(In reply to comment #43)
> Can't do that for attributes which have spaces without creating a custom dialog
> box, and if we're going to go to that much trouble, why not a macro to
> calculate and set the value automatically?

Would it be possible to get a macro (context menu) for selecting the LastReviewedStatus ?

BZDATETIME::2010-05-10 12:50:12
BZCOMMENTOR::William Osei-Poku
BZCOMMENT::47

I get the following error (on Mahler) when I use the macro or when I try to manually set the LastReviewed attribute.

Line 218, Column 8
Description: Object expected

BZDATETIME::2010-05-10 13:04:48
BZCOMMENTOR::Volker Englisch
BZCOMMENT::48

(In reply to comment #47)
> I get the following error (on Mahler) when I use the macro

Which macro is that you are using?

BZDATETIME::2010-05-10 13:12:49
BZCOMMENTOR::William Osei-Poku
BZCOMMENT::49

(In reply to comment #48)
> (In reply to comment #47)
> > I get the following error (on Mahler) when I use the macro
>
> Which macro is that you are using?

Right-click on the referenced protocol ID in the summary and select 'Set Last Reviewed Attribute'. I probably should have reported this error in OCECDR-2998 but since it is closed and we have used this issue to make at least one schema change, I decided to report it here. If you want me to re-open OCECDR-2998 let me know.

BZDATETIME::2010-05-10 13:34:09
BZCOMMENTOR::Volker Englisch
BZCOMMENT::50

(In reply to comment #49)
> I probably should have reported this error in OCECDR-2998

Yes.

> If you want me to re-open OCECDR-2998, let me know.

It'll make it easier to know who should fix the problem.
As I understand it now this comment was actually addressed to Bob and has nothing to do with the report since you're still able to enter the attributes even without the macro.

BZDATETIME::2010-05-11 16:48:36
BZCOMMENTOR::William Osei-Poku
BZCOMMENT::51

I have a few observations and questions:

1. When running the report for a single summary by entering CDR-ID in the user interface, it looks like only the CDR ID in the form of “CDR123456’ or ‘123456’ can be used?. It appears that the CDR ID is ignored when I enter ‘CDR0000062855’.

2. In some cases, when a CTGov trial is referenced in the summary, it does not display in the report. For example – 62855. When you run the report for one summary and enter the CDR ID 62855, and accept all defaults, the report displays all protocol refs with the exception of the Women's Health Initiative protocol (CDR 599223).

3. In another case, when I add CTGov protocols as ProtocolRefs in a summary and run the report, they are displayed by not as links in the report. For example: 62923. Enter 62923 as a single summary and accept all defaults. “790101” is displayed but not as a link. “Women's Health Initiative” is displayed but also, not as a link. “NCT00787761” is not displayed at all. Am I missing something?

4. When I select “Pediatric Treatment” and choose the date range 2010-05-01 and 2010-05-11, I get a python script error. This is possibly a data error but I don’t know which summary has the error.

BZDATETIME::2010-05-11 19:18:46
BZCOMMENTOR::Volker Englisch
BZCOMMENT::52

(In reply to comment #51)
> 1. When running the report for a single summary by entering CDR-ID in the
> user interface, it looks like only the CDR ID in the form of “CDR123456’ or
> ‘123456’ can be used?. It appears that the CDR ID is ignored when I enter
> ‘CDR0000062855’.

Actually, only the format '12345' was accepted, any entry that was not an integer resulted in running the report for all summaries.
I have changed this to accept any format for the CDR-ID.

> 2. In some cases, when a CTGov trial is referenced in the summary, it does
> not display in the report.

That's correct.
There was no mention in the original request to modify the way the existing report was selecting the ProtocolRef/Links and it was written to only select InScopeProtocols.
I have changed the report to also include CTGovProtocols.

> 3. In another case, when I add CTGov protocols as ProtocolRefs in a summary
> and run the report, they are displayed by not as links in the report.

That's correct. Because the CTGovProtocols were not included in this report at all some of the CTGovProtocol links just happened to be in the vicinity of an InScopeProtocol Ref which was displayed and therefore these CTGovProtocol "links" were displayed as plain text only.

> 4. ... This is possibly a data error ...

That's correct. If the date format is not in the proper format 'YYYY-MM-DD' the date conversion fails and we cannot compare the entered LastReviewed date with the selected date range.
I have now modified the program to test for a valid date format first and if it is found to be invalid the LastReviewed date is treated as if it did not exist (i.e. it will always be displayed but the inclusion/exclusion will be ignored).

Please verify on MAHLER.

BZDATETIME::2010-05-18 16:41:45
BZCOMMENTOR::William Osei-Poku
BZCOMMENT::53

(In reply to comment #52)
> (In reply to comment #51)
> > 1. When running the report for a single summary by entering CDR-ID in the
> > user interface, it looks like only the CDR ID in the form of “CDR123456’ or
> > ‘123456’ can be used?. It appears that the CDR ID is ignored when I enter
> > ‘CDR0000062855’.
>
> Actually, only the format '12345' was accepted, any entry that was not an
> integer resulted in running the report for all summaries.
> I have changed this to accept any format for the CDR-ID.
>
>
Verified. Thanks!

> > 2. In some cases, when a CTGov trial is referenced in the summary, it does
> > not display in the report.
>
> That's correct.
> There was no mention in the original request to modify the way the existing
> report was selecting the ProtocolRef/Links and it was written to only select
> InScopeProtocols.
> I have changed the report to also include CTGovProtocols.
>
Verified. Thanks!
>
> > 3. In another case, when I add CTGov protocols as ProtocolRefs in a summary
> > and run the report, they are displayed by not as links in the report.
>
> That's correct. Because the CTGovProtocols were not included in this report at
> all some of the CTGovProtocol links just happened to be in the vicinity of an
> InScopeProtocol Ref which was displayed and therefore these CTGovProtocol
> "links" were displayed as plain text only.
>
>
> > 4. ... This is possibly a data error ...
>
> That's correct. If the date format is not in the proper format 'YYYY-MM-DD'
> the date conversion fails and we cannot compare the entered LastReviewed date
> with the selected date range.
> I have now modified the program to test for a valid date format first and if it
> is found to be invalid the LastReviewed date is treated as if it did not exist
> (i.e. it will always be displayed but the inclusion/exclusion will be ignored).
>
> Please verify on MAHLER.

Verified. Thanks!

BZDATETIME::2010-05-20 16:06:45
BZCOMMENTOR::William Osei-Poku
BZCOMMENT::54

I just wanted to note here that In OCECDR-3162 the LastReviewed attribute is being changed to LastReviewedDate.

BZDATETIME::2010-05-25 11:20:07
BZCOMMENTOR::Volker Englisch
BZCOMMENT::55

I've changed the name of the attribute.

Please verify the program again on MAHLER.

BZDATETIME::2010-06-02 16:18:35
BZCOMMENTOR::William Osei-Poku
BZCOMMENT::56

(In reply to comment #55)
> I've changed the name of the attribute.
> Please verify the program again on MAHLER.

In the Excel, can you rename the last two columns the same way you have named them in the HTML format? Date should be ‘Last Reviewed Date’ and Last Status should ‘Last Reviewed Status’ (Just like the names of the attributes).

When these changes are completed, we will be ready to promote this to Bach.

BZDATETIME::2010-06-07 12:07:50
BZCOMMENTOR::Volker Englisch
BZCOMMENT::57

The following program has been copied to FRANCK and BACH:
SummariesWithProtocolLinks.py - R9658

Please verify on BACH and close this bug.

BZDATETIME::2010-06-15 15:46:13
BZCOMMENTOR::William Osei-Poku
BZCOMMENT::58

(In reply to comment #57)
> The following program has been copied to FRANCK and BACH:
> SummariesWithProtocolLinks.py - R9658
>
> Please verify on BACH and close this bug.

Verified on Bach. Issued closed. Thanks!