Issue Number | 5226 |
---|---|
Summary | Enable creation of Partner document without SVPC summaries |
Created | 2023-04-05 08:41:52 |
Issue Type | New Feature |
Submitted By | Dugan, Amy (NIH/NCI) [C] |
Assigned To | Englisch, Volker (NIH/NCI) [C] |
Status | Closed |
Resolved | 2023-04-10 16:40:32 |
Resolution | Fixed |
Path | /home/bkline/backups/jira/ocecdr/issue.342812 |
Business need: As part of the proof of concept for using the NCI Digital Platform for content modernization, we need a temporary workaround to provide legacy PDQ Patient Summary documents to PDQ Partners in current XML format and structure through the CDR, as this functionality does not exist in the NCI Digital Platform.
Assumptions
We will continue to publish this directly out of the CDR for PoC; modifying the NCI Digital Platform to provide structured XML back to the CDR or directly to the SFTP server would be a very significant lift and is not in scope for the PoC
We will accomplish without a release in the CDR or Cancer.gov
The following approaches were considered. Since Approach 1 is the only one that doesn't require a release, we would like to move forward with Approach 1.
Approach # |
Potential PoC Approach Desc |
PoC Approach Notes |
Pros |
Cons |
LOE |
Roadmap Notes |
1 |
Create only a partner document (without the individual SVPC pieces). |
We have implemented processing to collect the MainTopics from the SVPC document and the latest UpdateDate into the partner document. Cannot currently create/save a Partner document without SVPC docs in the CDR. Will require filter code updates to implement but NOT a release. Update filters to add in additional exceptions to allow a PDQ Partner document to be created manually without having SVPC documents. |
|
Adding complexity to filters |
Low (1 day of dev; 2-3 days of testing) |
Not a long-term solution; |
2 |
Create the individual SVPCs + partner doc in the CDR manually. |
For this we will need some code changes because these PoC SVPC documents must be excluded from being published to Cancer.gov |
Closest to the way things work now? |
|
TBD |
|
3 |
Create only a single document but don’t mark it as partner. We know this will process properly but programming changes will be necessary to exclude this “not-marked-as-partner” partner document from being published to Drupal |
We know this will process properly but programming changes requiring a release will be necessary to exclude this “not-marked-as-partner” partner document from being published to Cancer.gov |
|
|
TBD |
|
Question about Approach 1: Will it be possible to copy structured XML out of the current Stomach Cancer PDQ Patient summaries (Treatment, Screening, Prevention, Childhood) to "seed" the new manually created Partner summaries?
~oseipokuw, which are the documents that will need to be replaced? I need to have a look at the currently provided documents to get a better understanding on the structure - especially the possible use of ModuleLinks within those.
I believe these are the partner summaries with the corresponding Spanish translations. I may have to give a final confirmation later 🙂.
CDR0000798744
CDR0000062850
CDR0000315400
CDR0000271446
CDR0000256764
CDR0000760620
CDR0000760618
CDR0000800488
Will any of these documents be re-created using SummaryModuleLinks? I need to be able to distinguish real partner documents from these faux partner documents. I am planning to look if a partner document includes SummaryModuleLink elements to do that but it will only work if we're not using that element for the faux partner doc.
As far as I know, we will not be recreating these summaries as modules. Neither do we have any immediate plans to add SummaryMoudleLinks.
Probably we will just be marking them up as Partner summaries with minor updates like adding external ref links. So, it is unlikely that the summaries themselves will be recreated as modules. However, in the long term (assuming we will be taking this approach for future SVPC projects), it is possible that we may want to include module links depending on the situation although I do not have a use case. If that is going to be a problem, I think we should just be aware that we wouldn't be able to do that.
~duganal, I would like to confirm that these "special" Partner documents should follow the same rules as the "regular" Partner documents like (a) no toggle URL, (b) no 'About this PDQ' section, etc. Is that correct?
The following filter has been modified to address the issues with the Partner document without SVPC children:
CDR157.xml: Vendor Filter: Summary
How should I prepare the documents for testing?
Make them partner summaries (PartnerMergeSet=Yes)
Do I need to make them publishable?
Eventually, how are they going to be removed from Cancer.gov (Hot-fix Remove?)
Is there a need to block them before they are removed from Cancer.gov?
I haven't finished testing the different document paths or publishing events yet but here are the answers to your questions:
Make them partner summaries (PartnerMergeSet=Yes)
Correct
Do I need to make them publishable?
In order for testing a publishing job the documents will need to be
publishable, otherwise the old version would be published.
Eventually, how are they going to be removed from Cancer.gov
(Hot-fix Remove?)
The publishing software removes documents from Cancer.gov that are
marked as partner documents, so they should be removed as part of our
regular publishing job. If we'd block the document in order to remove
from CG with a hot-fix they also wouldn't be pushed to the
partners.
Is there a need to block them before they are removed from
Cancer.gov?
No, that should be automatic.
Of course, part of testing is to confirm (3) and (4) are still true for these faux partner docs.
As a test, I ran a weekly publishing job last night on the QA server after marking the document CDR62850 as a Partner document (without SVPC child documents). Although the publishing job as a whole failed, it is confirmed that this partner document would be marked properly and removed from Cancer.gov as part of the publishing job.
As discussed earlier, a document marked as PartnerMergeSet without including a SummaryModuleLink will be treated as special case partner documents.
I ran a diff report on QA to compare the result of the filter changes. Everything looks good so far. I will run a more complete diff report which also looks at the final vendor output once additional documents have been prepared.
The following filter has been modified:
CDR000157.xml - Vendor Filter: Summary
https://github.com/NCIOCPL/cdr-server/commit/b29874e
Yes, ~volker . Sorry for the delay. Always best to ping me outside of Jira if you need an answer. 🙂
That's OK, ~duganal , I already received the answer via telepathy and that's how the change has been implemented.
I have marked these as partner summaries on STAGE with non-publishable versions. Ready for the next steps.
~oseipokuw , if you could repeat these changes for the partner documents on QA, I will copy the filters and run another weekly publishing job.
~volker They are ready on QA.
The publishing output on QA has been reviewed. I ran diff reports and I did not see any unexpected differences resulting from the modified filter.
The filter change has been copied to STAGE and PROD.
The publishing job on Friday correctly produced the partner documents for stomach cancer. The only issue I see - not related to the filter changes - is the fact that the SummaryURL included in the partner documents isn't pointing to any page currently existing on CG.
This ticket is ready to be closed.
Verified. Thanks!
Elapsed: 0:00:00.001345