CDR Tickets

Is the problem that you will have to access multiple documents for the updates or that you have duplicated information in multiple documents?

The main problem is the duplicated changes in both the live doc and the shell doc, and even remembering to do that each time there is a change.

Your idea is to include the (modified) SummaryModuleLink to the shell doc and include the text from the live doc in the shell doc?

If you did that you would have to update only one document for the purpose of the QC report run for the shell doc but none of the changes would be available in the PublishPreview report or the individual QC reports for the smaller live docs.  You still would need to transfer all of the changes from the shell document back to the individual live documents.  You would have to update multiple documents and you would have to duplicate your work.  I wouldn't think that's preferable to updating multiple documents once.

**

  Your idea is to include the (modified) SummaryModuleLink to the shell doc and include the text from the live doc in the shell doc?

The idea is to include the SummaryModuleLink in the live doc but modified to ignore it during publishing or in PP. Currently, the module links have been removed from live doc but we had to put them in the shell doc to generate one QC report containing all the summary.  So, if there was a way to keep the module links in the live docs (without publishing the content of the modules), that would resolve the issue for us.

I'm sorry but I'm still not getting it.  

We're talking about the (blocked) shell doc which contains the SummaryModuleLinks to the smaller summaries, let's use van-Hippel as a representative for those broken out, smaller summary modules.  Is van-Hippel what you refer to as the "live doc"? If not which is the live doc?

I am referring to the Genetics of Renal Cell Carcinoma CDR0000574548  (live), CDR0000804574 (shell). I believe the Von Hippel-Lindau Disease summary is just one of the 4 modules linked to the shell doc. In the live doc, they are linked as SummaryRef(s).  So, if we can move the module links from the shell doc (assuming there is a modification to "mask" them), then we can abandon the shell doc, which we are maintaining only for the purpose of generating QC reports.

OK, now I'm getting it.  

We introduced summary modules, i.e. Peutz-Jeghers syndrome, to avoid duplicated maintenance.  Can't we do this here as well?  You stick the content for Genetics of Renal Cell Carcinoma in a separate module and then include that new module into both, the shell document and the live document?

~juther will take a closer look to see if Volker's proposed solution will work for this immediate case. We will also use this ticket to capture thoughts for the more general issue.

As discussed in the status meeting, one proposed solution is to add an attribute on the SummaryModuleLink element (maybe "QC Report Only") that would prevent this content from publishing to Cancer.gov and our partners, but be included in the QC report filters. Once a more concrete planned is formulated, we will create separate issues for the schema change, CSS changes (including COLOR!), and filter changes.

I've modified the schema to add the attribute 'IncludedWith'. When the user sets this attribute to 'qc-only', the denormalization for modules will exclude that specific SummaryModuleLink unless you're running a QC report.

As a test I've added two SummaryModuleLinks to the 'Small Intesting Cancer Treatment' summary (CDR62902), one with that attribute set and one without.

Please take a look on DEV if this would accomplish what you're looking for, ~oseipokuw.

 I've modified the schema to add the attribute 'IncludedWith'. 

If it is not too late can you rename the attribute as "UsedFor" ? the "qc-only" value is fine.

It's not too late.  I made those changes on DEV.  

Please be aware that any document you already modified with the new attribute is now invalid.

The following files have been updated:

• CdrCommonBase.xml (Schema)
  https://github.com/NCIOCPL/cdr-server/commit/4d74d07

• CDR712005 - Denormalization Filter: Summary Module
  https://github.com/NCIOCPL/cdr-server/commit/cac8979

Will you make the CSS changes for the display as part of this ticket or I should create another ticket for that?

Do we already know what the display should look like?

We can cover those changes as part of this ticket.

What do you think about this CSS change for the qc-only module link?

(Jira ate the attachment)

Looks good to me. ~juther Robin may want to weigh in as well.

This ticket is waiting for a quick peek by ~juther.

A sample screenshot is attached.

Ning will also take a quick look before we finally sign off 😃

This looks great to me! Thanks.

Verified on DEV. Thanks!

Verified on QA. Thanks!

We were reviewing this issue today and I think we came across an issue that may require a technical solution/modification. When we pull in the module text into the QC report, the summary title from that module is not displayed (I think this is by design from how we set up modules). This is problematic given that we don't want to add headings to the overview document if the content is only being displayed in the QC report, nor do we want to add additional headings in the module summary since that is published to Cancer.gov.

This is probably best shown with an example - I've mocked up the Genetics of Renal Cell Carcinoma summary on QA with two SummaryModuleLink elements with the QC-only attribute. These links are to the von Hippel-Lindau disease module and the hereditary leiomyomatosis and renal cell carcinoma module. However, when you run the QC report for the overview summary, there isn't a heading for the VHL text nor is there one for the HLRCC text. The sections just run together.

Yes, that's correct.  Since a Module can also be published as a stand-alone summary it must include all of the "Summary" elements, including a SummaryTitle but the SummaryTitle wasn't always desired when pulling in the content of a module, so we had setup the ModuleLinks to pull in the document content starting at the Section level and excluding SummaryTitle and SummaryMetaData.

There are several ways to address this.  Let's discuss which might be the least disruptive approach or most beneficial one.

I mentioned a couple of weeks ago about another issue with this report we wanted addressed. I was going to wait until after the release to enter a ticket but since you're addressing the above issue in this release, I will record it here just in case you want to address both of them in this ticket.  

From CIAT's perspective, we run the QC reports for the main summary and the modules individually. Generally, we will not be running the report to see all the content from the main summary and all the linked modules. So, we suggest that we have  a new  Misc. Print Option (e.g. Run as Board Member QC Report?)  item to run the report. Essentially, it should be optional to run the report this way instead of the current default.

Are you saying you would want an additional option which controls and overwrites the display of the module content regardless of the UsedFor attribute?  In other words, you want to be able to turn off the new functionality (for QC reports only) that we're trying to implement?

That is right. What we are implementing now is specifically to be able to generate a QC report that contains all the content in one place for the board members review. However, in many cases, when we use the QC report, we are using it for the individual documents and not for the documents put together. So, having the option to run the report for the board members and also having the option to run the report for our review is what we desire.

After getting some more information about the additional requirements and looking at the set of filters used for processing summaries, it seems that the needed modifications are significant enough to delay the changes.  These are the reasons:

1. When we talked about this yesterday, my original thought was we could just modify the module denormalization filter, include the SummaryTitle for the module, carry it along the process and display as part of the QC report.  However, as discussed with ~juther, a SummaryTitle will need to be a child of a SummarySection.  Therefore, it will be necessary to create a parent SummarySection to contain the module's SummaryTitle along with the SummarySection(s) content coming from the module.

2. With this additional SummarySection we may or may not - depending on the chosen implementation - need to adjust the portion of the filters responsible for creating the TOC section.

3. One of the more challenging issues when dealing with modules is the fact that cdr:ids are unique within each document.  However, when combining/importing content from one document into another one, this uniqueness is not guaranteed anymore and needs special attention.  We need unique cdr:ids within a document because these IDs are used when we're creating anchor links to jump to specific sections.  Given that the new module SummarySection will only need to be included for QC display purposes, Robin already said we won't need to make this module SummarySection linkable and there is no need to link to it from its TOC entry, for instance.  I can't say for sure we won't need to deal with these section IDs for other reasons but if we do, it would make the required changes "more interesting".

4. ~oseipokuw , added a comment indicating that CIAT would like the ability to "turn off" the inclusion of the QC only module documents. I'm glad he included this comment here, because the implementation for that request may have an impact on the path we want to follow for the other changes that are needed.  We could, for instance, add a button to hide the module section, which would require a unique ID for the module section (see #3).

Based on my initial look at the required filter changes, I feel we will need to modify a number of filters in the Summary filter set which will require a significant amount of testing to ensure all of the different paths for processing summaries (QC vs. PP, HP vs. patient, RS vs BU, English vs Spanish, etc.) are looked at.  

My recommendation would be to follow ~mbeckwit's suggestion from yesterday and keep what we have now for Newton and create a ticket with these additional changes for the next release.

I agree with the plan to leave the enhancement as is for Newton and address these other issues in the next release. Thanks for the explanation, ~volker!

~juther Is the work being done for this ticket (and the other two Newton tickets still outstanding) still being reviewed? Yesterday was the last day of UA testing, I believe, at least as originally planned. Do we need to extend?

Since the additional changes will be postponed until the next release I've moved the status for this ticket back to 'DEV verified'.

~oseipokuw, please go ahead and create a new ticket for Ohm with your request to create an option to overwrite the module display in QC reports.  I will create the ticket for the enhancement of this report (adding the module title along with the sections).  Let's link both of those tickets to this one.

I have created OCECDR-4985  and added it to Ohm.

Moving this to QA verified. Thank you!

Closing this ticket for now. Will create a new ticket if we come across any issues.