CDR Tickets

Is the order in which the individual cancers are currently displayed to be kept or will we create a single document with the cancers sorted alphabetically or use some other sorting mechanism?

I'm adding Sharon to this issue so she can comment. I don't know what the plans are for the sequence of the cancers.

Just wanted to confirm that Sharon does want the summaries to appear in groups by body system (as they are now).

I think the idea of using an element in the document or something along those lines will be helpful for dictating the sequence/grouping of the content in the merged report. Ideally, we'll come up with a solution that is flexible enough that we can use it as we add more unusual cancer summaries and in other summaries, too.

Ideally, we'll come up with a solution that is flexible enough that we can use it as we add more unusual cancer summaries and in other summaries, too.

One idea could be to create a summary document that would need to be marked as NotPublishable and then include the individual childhood summaries via a new ChildSummaryLink element, for instance, used just like SummaryModuleLink elements. It would allow us to still create an introduction for the combined summary report and maintain it in the CDR. The summary would only contain these ChildSummaryLinks along with the introduction.

Is it correct that the merged report will need to mimic the BU QC report or is the RS report needed as well?

Ideally, we'd like to have the merged QC report work for both types of reports - B/U and RLSO. The most pressing need is for the RLSO version since that's what Sharon uses.

I'm wondering why you would need the RLSO report. It's not used for the board members, I thought, and the editing of the documents would be done via the individual summaries.

I'm sure it's not a big deal either way but would add two buttons to the summary toolbar instead of one.

I'm pretty sure Sharon does use the RLSO version for her Board members, possibly because it shows all deleted text.

It appears that the SummarySection title, i.e. "Thyroid Tumors", has become the SummaryTitle element in the split summaries with the word "Childhood " added. If we're denormalizing the document as a module we're not including the SummaryTitle in the parent document and the section would start with a summary section called "Incidence".

We may not be able to create our QC report by assuming the unusual cancer summaries are regular module documents in order to include the SummaryTitle and modify the title.

The shell summary doc solution seems to work well for Sharon's QC report needs, although we were wondering if it would be possible to add something to Sharon's macro (or a new macro) to delete the redundant "Special Considerations" section from each of the smaller summaries (this section isn't in the smaller summaries yet but it is something she plans to add). She said this section will have the exact same title for each summary so perhaps the macro could pick up on that as it does for the Changes Section?

It should be possible to remove the Special Considerations section using a Word macro but it would likely be easier and less error-prone to eliminate a section using a filter. However, given the fact we now want to use the standard QC reports for the unusual cancers I'll have to think how to include a new filter that's not affecting any other reports.

Just to clarify, I'm calling it the "Special Considerations" section, but I think the title is longer than that. Sharon will have to provide the complete title when we need it.

We discussed the possibility of using a SectionType metadata for these "Special Considerations" sections and having an option on the QC report that would remove this section (through the filter) when selected.

Robin says that the existing QC report, combined with the shell document she has cobbled together, will meet most of their needs. However, it is likely that Sharon will also need a custom interface for this report which gives her the option of excluding a portion of the separate summaries. Story point estimate represents the work to implement this interface.

Per my previous comment we had talked about using SectionType metadata and adding an option on the existing QC reports to remove this section. So, there will likely be a small schema change and a filter change with the addition of a checkbox on the QC report interface.

I talked with Sharon and we came up with the following answers to the questions that came up in our meeting today:

1) Every "Special Considerations" section can be removed from the Unusual Cancers summary QC report. There's no need to preserve one instance of this section.

2) We would like the software to determine whether or not to display the "Special Considerations" section with the following logic: if it's a QC report of the module summary, please display it; if it's the QC report of the parent doc and the included modules have this section, do not display it. This means that we do NOT need a checkbox.

3) Please use the following value for the SectionType attribute: "Unusual Cancers Special Considerations". Hopefully, that isn't too long, but if it is, let us know. We could probably drop the word cancer if we need to.

You mentioned that this could be a release independent change if we don't need a checkbox, but I think we'll still need a release to get the schema change into production, right? If not, let me know and I'll move this to the release independent queue.

Thanks!

Could you tell me the CDR-ID of the parent document on DEV or do I have to read through Bob's conversion task?

CDR0000780676 - Unusual Cancers of Childhood - TEST SHELL DOC

We would like the software to determine whether or not to display the "Special Considerations" section with the following logic: if it's a QC report of the module summary, please display it; if it's the QC report of the parent doc and the included modules have this section, do not display it.

In other words: Display a regular QC report unless it's the shell document.
In addition to removing the "Special Consideration" section from the text it has also been removed from the TOC. However, that portion of the filter changes only functions properly when that section is a top-level SummarySection.

The following documents have been updated.

• SummaryCommon.xml (schema)

• CDR339576.xml: Module: InLine Markup Formatter

For my information:
These changes are located in cdr-server (fermi)/index.

I've updated CDR780672 and CDR780673 on DEV for testing.

This is ready for review on DEV.

Changes have been versioned in git (fermi branch):

• SummaryCommon.xml (1b75d4fb)

• CDR339576.xml (1b75d4fb)

~bkline, in case I get hit in the head by a tennis ball over the weekend and forget, this change has not yet been pushed to github. I'm waiting for the review on DEV before pushing it but want you to know that it's currently missing in the (test) build.

This looks good to me! I've asked Sharon to take a look too before we test this on QA.

~bkline, I've updated the fermi branch on github with my changes.

Hi ~squint, did you have a moment to take a look at these changes for your Unusual Cancers QC report?

Sharon confirmed that the changes look good.

~bkline, it doesn't look like the schema change for the new Section Metadata Section Type value made it to QA. Could you please add it? Thanks!

Done, thanks.

Verified on QA.

Unable to verify this one yet, but I'll reopen if there's a problem.

Reopening this ticket so we can revisit the possibility of having an unusual cancers-specific QC report. The complications associated with this may be worthwhile given the module-within-module problem. This is not an immediate need, so I have lowered the priority.

Creating a specific QC report for this purpose is MUCH less work than addressing the module-within-module problem (which would likely require rewriting the full summaries filter set). It will be important to consider the flexibility of the new report when it is developed to allow for revised summary titles, new cancer types, and deleted cancer types. We will still need to delete the redundant special considerations section in this new report.

The changes referenced above and completed in September 2017 to strip the Special Considerations sections of the Unusual Cancers summary no longer seem to be in place on PROD. Sharon ran a RLSO QC report of the Unusual Cancers summary and the Special Considerations section within each of the modules is displaying on the report. I believe this is a filter issue. Perhaps something was inadvertently replaced during the Hawking update?

I ran a PublishPreview report and that does not show the Special Consideration section, so Cancer.gov is OK, right?

Yes, Cancer.gov is OK.

~bkline, I'm guessing this is a problem I created. I'm thinking I probably updated the filter for hawking without merging master into hawking first before pushing the changes. I'm hoping you can help me understand which step I've missed.

I'll restore the changes, Robin, and let you know when it's done.

From what I can tell, it looks as if you applied commit 1b75d4f on September 22, suppressing the Unusual Cancers Special Considerations sections. Then on March 20 you applied commit e1127ab, removing the change you had committed in September.

That's correct but I didn't actively remove the change. I'll have to go through my comments and think about it a little more but I believe the section was removed by merging branches. Most likely I pushed a local branch to github without having first merged master into the local branch - or something like that.

The filter changes to remove the Special Considerations section have been restored on STAGE and PROD.

• CDR339576: Module: InLine Markup Formatter
  https://github.com/NCIOCPL/cdr-server/commit/bbfdf20

Please verify on PROD.

~juther, can we close this ticket or is there a reason why we need to keep it open at this point?

So the direction of this issue has morphed a couple of times, but I think we should keep this open based on the comments on Jan 30 and Feb 8. I believe we still will need to create a QC report specific to the Unusual Cancers summary since we have the problem of modules within modules.

Decided this is not needed at this time. Will reopen if we need it at a later date.