CDR Tickets

BZDATETIME::2010-12-13 13:07:56
BZCOMMENTOR::Volker Englisch
BZCOMMENT::1

I am guessing that the SummaryType will not have any influence on the display of the Comments, regardless of the values that are set for these new attributes.
Is that correct?

BZDATETIME::2010-12-14 09:48:28
BZCOMMENTOR::Robin Juthe
BZCOMMENT::2

Yes, that is correct. Thanks.

BZDATETIME::2010-12-15 17:30:05
BZCOMMENTOR::Volker Englisch
BZCOMMENT::3

(In reply to comment #0)
> These options could be:
>
> - Display permanent comments
> - Display Advisory Board comments

Currently we have two check-boxes titled 'Board Markup' with the options

• Editorial board markup and

• Advisory board markup

If we agree that users will only want to see Advisory Board comments when they are selecting the Advisory Board Markup option (and vica versa) then - I believe - we could get away with a single additional option for the comments:

• Include Permanent Comments

However, if there is a need to turn the temp. Comments on or off we will need a pair of comments like this

• Display temp. Comments

• Display permanent Comments
  and display the comments only if the attribute value is matching the selection.

We also need to talk about the presentation of the individual comment types if we're expecting to have each of them displayed differently (i.e. advisory-board comments in italics, permanent comments in bold, etc).

So, the three questions that I have are:
1) Will the Board markup selection decide of the comment source display?
2) Do we need to turn temp. comments on/off?
3) Do we want to display different comment types differently?

BZDATETIME::2010-12-16 11:44:05
BZCOMMENTOR::Robin Juthe
BZCOMMENT::4

(In reply to comment #3)
> 1) Will the Board markup selection decide of the comment source display?

It IS possible that we would want to display markup without comments, such as for a Board meeting, so I think it's important to have this option separate from the decision to show Advisory Board markup.

> 2) Do we need to turn temp. comments on/off?

By temporary comments, you mean any comment that is not permanent, right? Internal/External and Advisory Board? Yes, I think we need to have this option to display or hide these types of comments.

Although complicated, I think we need a lot of options in order to satisfy each case. Could we solve it this way?:

• Show ALL Comments (any audience, any duration, any source)

• Hide Advisory Board comments (excludes those with source=Advisory Board with any audience and any duration)

• Hide Permanent comments (excludes those with duration=permanent with any audience and any source)

• Hide Internal comments (excludes those with audience=Internal with any duration and any source)

• Hide External comments (excludes those with audience=External with any duration and any source)

The default could be to hide Permanent comments and Internal comments.

> 3) Do we want to display different comment types differently?

This is an interesting question that I hadn't considered. I think it would be good to display comments differently though - especially those from the Advisory Board to differentiate to Board members which comments were from within their group and which were from external reviewers. Volker, I'll let you get creative here. :-)

BZDATETIME::2010-12-28 18:51:44
BZCOMMENTOR::Volker Englisch
BZCOMMENT::5

I have added the display options based on the comment attributes to the filters as a test case. At this point it only works for the test document CDR62770 (Breast Cancer Treatment and Pregnancy) on MAHLER for Redline/Strikeout QC reports (or to be precise for compact lists only).
I've added the check boxes for the new attributes with these display formats:
a) audience - Internal/External
External display - font color white
Internal display - font color light-blue (or something like that)
b) source - editorial-board/advisory-board
editorial-board - text spacing normal
advisory-board - text spacing wide (like advisory board
insertion/deletion)
c) duration - regular/permanent
regular - background green
permanent - background greenish blue

It may be good if I could get some input on how this is currently working and how it's displayed before I finish everything else.
Also, I'm not certain - given the different display properties for comments at this point - if we still want to mark up Comments for insertion/deletion for RS and BU reports.
Please note that the display of the comments is an intersection of the three attribute values and the selected display check boxes. If any of the check-boxes is unchecked that particular comment will not be displayed regardless of the values for the other two attribute values.

I was also wondering if we want to modify the page with the check-boxes to display like most of the more recent pages with the centered display of the options similar to the Linked Documents Report?

BZDATETIME::2011-01-04 15:41:55
BZCOMMENTOR::Robin Juthe
BZCOMMENT::6

(In reply to comment #5)
> It may be good if I could get some input on how this is currently working and
> how it's displayed before I finish everything else.

Margaret, Sharon, and I met today to talk about how we plan to use the comment attributes and to review your suggested changes. We think that although this solution would allow for every possible type of comment, we'd like to make it a little simpler (we think) and only give the options that we envision we will need. Here's what we came up with:

1. Display Internal Comments (Except Internal Permanent Comments)
2. Display All Permanent Comments (Internal & External)
3. Display External Comments (Except External Advisory Board Comments)
4. Display Advisory Board Comments (Internal & External)
5. Display ALL Comments

The default option would be #3, but users could select one or more options above.

> Also, I'm not certain - given the different display properties for comments at
> this point - if we still want to mark up Comments for insertion/deletion for RS
> and BU reports.

I don't think it's necessary to mark up comments in insertion/deletion markup, but it would probably be best if I run this past the group (or at least Margaret weighs in) before you change the way that works now.

However, we also talked about the display of different types of comments and decided that it would be more helpful if the comments were distinguishable using text rather than color/formatting because we often provide the summaries to our Boards in black & white, and the Board members are confused enough by the difference between bold and bold italic text meaning the changes came from different places. For Advisory Board comments, we thought it would be helpful if we could have the comment automatically add an "AB: " at the beginning or maybe that it could say "AB Comment: " rather than "Comment:" at the start of the comment. For Permanent comments, it could say "Permanent Comment: " at the beginning of the element, or just "Permanent: " after the word Comment. Would something like this be feasible?

> I was also wondering if we want to modify the page with the check-boxes to
> display like most of the more recent pages with the centered display of the
> options similar to the Linked Documents Report?

Sure, let's make it pretty!

Thanks, Volker.

BZDATETIME::2011-01-04 15:47:02
BZCOMMENTOR::Robin Juthe
BZCOMMENT::7

(In reply to comment #6)
> and only give the options that we envision we will need.

*Small self-correction: This solution would also allow for every possible type of comment, but we're just grouping them in the ways we think they will most commonly be used.

BZDATETIME::2011-01-04 16:31:30
BZCOMMENTOR::Volker Englisch
BZCOMMENT::8

(In reply to comment #6)
> 1. Display Internal Comments (Except Internal Permanent Comments)
> 2. Display All Permanent Comments (Internal & External)
> 3. Display External Comments (Except External Advisory Board Comments)
> 4. Display Advisory Board Comments (Internal & External)
> 5. Display ALL Comments
>
> The default option would be #3, but users could select one or more options
> above.

I'm not sure that more than one option would make sense unless maybe in some special cases. For instance, option (1) and option (2) together doesn't make much sense and neither does option (5) with any of the other options or the meaning of the combination of options would be confusing for the users, don't you think?
I will try to map your options to the six options currently available to see what's left that hasn't been covered.

> I don't think it's necessary to mark up comments in insertion/deletion markup

Since I had written that statement I have already modified the code to display comments in insertion/deletion markup for parts of the report.

> decided that it would be more helpful if the comments were distinguishable
> using text rather than color/formatting

The report could also use text and color/formatting (at least I think at this point that it's possible). At the moment I have only formatted the RS report and haven't touched the BU report at all. If the RS report is used to be printed for Board Members I would agree that the different types of markup will be too confusing (it's confusing to me!) but if it's mainly for internal use we can try to use both, color and text labels to indicate the different comment types. I would argue that it's particularly helpful when you display all comments.
The BU formatting, obviously, will need to be labeled mainly with text as you have indicated and if I change the filters in this fashion the labels will also show up for the RS report regardless unless we add special programming to suppress this.

BZDATETIME::2011-01-07 16:11:52
BZCOMMENTOR::Volker Englisch
BZCOMMENT::9

(In reply to comment #6)
> For Advisory Board comments, we thought it would be helpful
> if we could have the comment automatically add an "AB: " at the beginning

You are probably going to tell me that this is not going to happen but just in If an advisory comment has been marked as 'permanent' what should the label look like?
a) AB-Comment
b) Permanent-Comment
c) AB-Permanent-Comment
d) Permanent-AB-Comment
e) Other

BZDATETIME::2011-01-07 17:18:09
BZCOMMENTOR::Robin Juthe
BZCOMMENT::10

(In reply to comment #9)
> (In reply to comment #6)
> > For Advisory Board comments, we thought it would be helpful
> > if we could have the comment automatically add an "AB: " at the beginning
> You are probably going to tell me that this is not going to happen but just in
> If an advisory comment has been marked as 'permanent' what should the
> label look like?
> a) AB-Comment
> b) Permanent-Comment
> c) AB-Permanent-Comment
> d) Permanent-AB-Comment
> e) Other

I suppose it COULD happen :-), though it would be rare, so let's go with option d) Permanent-AB-Comment.

Thank you!

BZDATETIME::2011-01-11 11:54:15
BZCOMMENTOR::Volker Englisch
BZCOMMENT::11

I wanted to double-check something:
We've always been talking about the Comment and it's attributes.
Do these changes also apply to the ResponseToComment fields, i.e. changing the labels to AB-Response, Permanent-Response, ...?

BZDATETIME::2011-01-11 14:11:28
BZCOMMENTOR::Robin Juthe
BZCOMMENT::12

No, we decided we will not be using attributes on responses, but if we do, they will always be accompanied/preceded by a comment, so it's not necessary to label the responses as permanent, AB, etc.

BZDATETIME::2011-01-13 17:50:08
BZCOMMENTOR::Volker Englisch
BZCOMMENT::13

I've finished the RS QC report and the user interface on MAHLER but I forgot that I will still need to address the BU QC report before this is complete. I should be able to finish the BU report sometime tomorrow and then do some more testing.

BZDATETIME::2011-01-18 16:46:22
BZCOMMENTOR::Volker Englisch
BZCOMMENT::14

I can't keep all of the different test cases in my head anymore, so I created a cheat sheet.

Attachment TestComments.txt has been added with description: List of test cases for Comment display

BZDATETIME::2011-01-20 18:01:55
BZCOMMENTOR::Volker Englisch
BZCOMMENT::15

The following filters have been modified:
CDR380957.xml - Module: STYLE RS Insertion Deletion
CDR380958.xml - Module: STYLE QC Summary
CDR380956.xml - Module: STYLE BU Insertion Deletion
CDR335166.xml - Module: Checkbox Formatter

as well as the program
QcReport.py

Please note the following changes:

• The parameter page has been modified
  As listed in Comment #5, I'm now displaying the options in HTML fieldset
  elements which are centered on the page similar to many of the more recent
  reports we have implemented.
  Some of the improvements that come along with this is the fact that we're
  able now to click on the text of the label in order to select the checkbox.
  You don't have to check the checkbox itself anymore.

• For the Comment options we're allowing five options as listed in Comment #6.
  For these five options only option 1+2 or 3+4 can be combined based on the
  requirements.

• Option 1 (Internal comments) and Option 3 (External comments) are different
  from displaying all internal or all external comments. If only those
  comments should be displayed the options will have to be selected manually.
  The user will have to click the link under 'individual options'.
  This will display all available options to choose from.

CSS color/background display:
I have currently not adjusted the CSS for the display of the requested colors and backgrounds to only distinguish between external and internal comments.
My feeling is that it will be useful to keep the current CSS to help during the testing phase. The current CSS is defined as follows:

• All comments are displayed in bold, italic

• regular comments have a green background and yellowish text
  (black text in BU reports)

• permanent comments have a teal-blueish background and white text
  (black text in BU reports)

• editorial comments have normal letter spacing

• advisory comments have wider letter spacing

• inserted comments should all be red

• deleted comments have black text

Comment Lables:

• all comments display the label [Comment:]

• advisory board comments display the label [AB-Comment:]

• permanent comments display the label [Permanent-Comment:]

• permanent, advisory comments display the label [Permanent-AB-Comment:]

Testing:
I've already included the list of test cases as an attachment. I have worked with the HP summary CDR62770. It might therefore be a good idea to use a patient summary for extensive testing and only spot check a few more HP summaries. Please note that the following items need to be tested separately:

• Comments in lists (compact lists)

• Comments in lists (non-compact lists)

• Comments in normal text

• Comments in RS reports

• Comments in BU reports

• Comments in HP summaries

• Comments in patient summaries

• Comments in insertion markup

• Comments in deletion markup

Since almost all of the modified filters are shared between other document types, testing also needs to include QC reports for these document types at least to confirm that I didn't break anything:

• Summaries

• DrugInfoSummaries

• GlossaryTermName

• GlossaryTermConcept

• Misc. Docs

• Person Docs

This is ready for testing on MAHLER.

BZDATETIME::2011-01-27 17:18:09
BZCOMMENTOR::Robin Juthe
BZCOMMENT::16

I tested extensively with CDR62860 (Childhood Brain Tumor Overview – HP summary). As expected, the comments all seemed to be displaying correctly with regard to the options chosen on the report interface. I noticed a couple things though:

1. All formatting of the comments was lost when I converted the RLSO QC report into Word. (The comments appeared as regular text.)

2. In the B/U report, many of the comments were preceded by “222a”. For example, “222a [Comment: List option 2. External comment.]”. This text was not in the XML or on the RLSO report but only appeared on the B/U report.

I have not tested the patient QC reports, but I wanted to point out something about the patient QC interfaces. Since there is not a need for Advisory Board comments in the patient summaries, the QC report interface does not need the option to display advisory board comments. The options could instead be Internal (no permanent), Permanent (internal & external), External, and All comments. For the sake of simplicity (like anything about this is simple!), we could just use the same options as in the HP report and leave it as "external (no advisory)" and delete the advisory board line. I don't know how much reprogramming it would entail otherwise. Since advisory comments will not be used in the patient summaries, this would in effect be the same as "external (including advisory)".

I also have a couple questions about what to QC for the patient summaries. Does it matter if I test using a reformatted or unreformatted patient summary?
And just to be sure I understand, the following patient summary QC reports will need to be tested, right?

1.Bold/Underline (HP/Old Patient)
2.Redline/Strikeout (HP/Old Patient)
3.New Patient

William, would you mind looking at the other document types Volker mentioned?

testing also needs to include QC reports for these document types at
least to confirm that I didn't break anything:

• DrugInfoSummaries

• GlossaryTermName

• GlossaryTermConcept

• Misc. Docs

• Person Docs

Thank you!

BZDATETIME::2011-01-27 17:47:47
BZCOMMENTOR::Volker Englisch
BZCOMMENT::17

(In reply to comment #16)
> 1. All formatting of the comments was lost when I converted the RLSO QC
> report into Word. (The comments appeared as regular text.)

Bummer! That shouldn't happen since I'm specifying the comments in the way that Word likes it. I'll need to do more research on this one.

> 2. In the B/U report, many of the comments were preceded by “222a”.

That's test-text for me. I thought I had removed all of them.

> I have not tested the patient QC reports, but I wanted to point out something
> about the patient QC interfaces. Since there is not a need for Advisory Board
> comments in the patient summaries, the QC report interface does not need the
> option to display advisory board comments.

I'll have to think about how to handle this a little more. I will probably just hide the option but leave everything as is (with a big comment in the code).

> Does
> it matter if I test using a reformatted or unreformatted patient summary?

The unreformatted patient summaries behave just like the HP summaries, so testing with the reformatted once make the most sense. You'll "hit" different templates that way.

> the following patient summary QC reports will
> need to be tested, right?
>
> 1.Bold/Underline (HP/Old Patient)
> 2.Redline/Strikeout (HP/Old Patient)
> 3.New Patient

You have tested the HP summary type extensively and everything looks good so far. Therefore, the more you test the less likely it will be to find something that's still wrong and you probably don't need to be as thorough going forward. However, you do want to make sure that the commonly used functionality is still working alright. Obviously I've tested a bit myself already but I may not be using the comments/options the way the board managers do.
In short, the answer is 'Yes'.

BZDATETIME::2011-02-10 16:38:02
BZCOMMENTOR::Volker Englisch
BZCOMMENT::18

I've copied the filters that Bob rescued from MAHLER to FRANCK for testing and - for you, Robin - I was able to find a copy of the 'Breast Cancer Treatment and Pregnancy' with all of the different comment types on my local system and saved it on FRANCK (CDR62770).

Please go ahead and test on FRANCK.

BZDATETIME::2011-02-11 09:28:54
BZCOMMENTOR::Robin Juthe
BZCOMMENT::19

(In reply to comment #18)
> I've copied the filters that Bob rescued from MAHLER to FRANCK for testing and
> - for you, Robin - I was able to find a copy of the 'Breast Cancer Treatment
> and Pregnancy' with all of the different comment types on my local system and
> saved it on FRANCK (CDR62770).
> Please go ahead and test on FRANCK.

Thank you! I will test today.

BZDATETIME::2011-02-11 17:31:05
BZCOMMENTOR::Robin Juthe
BZCOMMENT::20

Okay, I tested both the HP and Patient versions of the Breast Cancer Tx and Pregnancy summary on Franck and the RLSO and B/U QC reports for both summary types and the comments displayed correctly in terms of the attributes and the types selected for display. The new interface for the patient QC reports (without the advisory board option) also looks good. Hooray!

In terms of display/color options, I talked with Sharon today since she is a "power user" of comments. We both agreed that we don't need to have so many colors for different types of comments on either the RLSO or B/U report. She also described some problems with the current green background for comments on the RLSO report becuase this doesn't copy well.

So, here's what I propose for BOTH the B/U and RLSO reports (HP & Patient):

• Internal comments - black, bold, italic text, normal character spacing. Light gray background.

• External comments - black, bold, italic text, normal character spacing. No background color.

Comments that are inside an insertion element do not need to display differently than comments that are not in insertion tags. However, we do still want comments that are in deletion tags to be struck through.

Thank you Volker!! We're getting there :-)

BZDATETIME::2011-02-11 17:32:43
BZCOMMENTOR::Robin Juthe
BZCOMMENT::21

(In reply to comment #20)
> Okay, I tested both the HP and Patient versions of the Breast Cancer Tx and
> Pregnancy summary on Franck

Actually, the patient summary I tested was Neuroblastoma. CDR258023.

BZDATETIME::2011-02-14 15:16:41
BZCOMMENTOR::Volker Englisch
BZCOMMENT::22

(In reply to comment #20)
> - Internal comments - black, bold, italic text, normal character spacing.
> Light gray background.
>
> - External comments - black, bold, italic text, normal character spacing. No
> background color.

I've made the color/spacing changes on FRANCK. Could you have another quick peek?

> We're getting there :-)

Are we there yet?

BZDATETIME::2011-02-14 16:01:35
BZCOMMENTOR::Robin Juthe
BZCOMMENT::23

(In reply to comment #22)
> Are we there yet?

Very close!

Two things:

1. The comments that are in insertion tags do not need to be red or underlined, but this is okay.

2. The light gray background on Internal comments is lost when converting any of these reports to Word.

BZDATETIME::2011-02-14 16:43:03
BZCOMMENTOR::Volker Englisch
BZCOMMENT::24

(In reply to comment #23)
> 2. The light gray background on Internal comments is lost when converting any
> of these reports to Word.

I'm afraid Microsoft doesn't allow me to convert a background color to Word. I've searched on the Internet for any hints to achieve this but haven't been able to come up with anything at this point.

If I can find a sample where the conversion of a background color does work maybe I can find out what I'm doing wrong.

BZDATETIME::2011-02-15 14:33:40
BZCOMMENTOR::William Osei-Poku
BZCOMMENT::25

> William, would you mind looking at the other document types Volker mentioned?
>
> testing also needs to include QC reports for these document types at
> least to confirm that I didn't break anything:
> - DrugInfoSummaries
> - GlossaryTermName
> - GlossaryTermConcept
> - Misc. Docs
> - Person Docs
>
> Thank you!

We have reviewed the QC reports for the above document types on Franck and they all look good. We did not find any problems.

BZDATETIME::2011-02-15 19:51:28
BZCOMMENTOR::Volker Englisch
BZCOMMENT::26

I've discussed with Robin that we want to put these changes into production and not wait for a resolution of the Word/Background issue.

BZDATETIME::2011-02-16 16:23:19
BZCOMMENTOR::Volker Englisch
BZCOMMENT::27

The following filter have been copied to FRANCK and BACH:
CDR335166.xml - Module: Checkbox Formatter - R10032 (OCECDR-3277)
CDR339576.xml - Module: InLine Markup Formatter - R10032 (issues OCECDR-3280, OCECDR-3245)
CDR380956.xml - Module: STYLE BU Insertion Deletion - R10032 (OCECDR-3277,4934)
CDR380957.xml - Module: STYLE RS Insertion Deletion - R10032 (OCECDR-3277,4934)
CDR380958.xml - Module: STYLE QC Summary - R10032 (OCECDR-3277,4970,
4934)
CDR409593.xml - Copy XML for Summary Report - R10032 (OCECDR-3280)
CDR434822.xml - Module: QC Filter Templates - Summary - R10032 (OCECDR-3280)

The following program has been copied to FRANCK and BACH:
QcReports.py - R10033

Please verify on BACH and close this bug.

BZDATETIME::2011-02-18 09:53:31
BZCOMMENTOR::Robin Juthe
BZCOMMENT::28

Verified on BACH; closing this bug. I think this calls for a celebration!!
Thanks so much for your work on (and patience with) this issue Volker. :-)