CDR Tickets

As we are getting closer to production with the changes to clinical trials we may want to start working on this issue, or at least pick a time to work on it.

JIRA issue OCECTS-116 is about changes needed to cancer.gov when large numbers of closed but published trials are blocked from publication on cancer.gov itself and links to them must be re-targeted to the ClinicalTrials.gov site. This OCECDR issue is concerned with the same problem.

CDR and cancer.gov efforts will need to be coordinated to be sure that those parts of the work best done on one system are done on that system, that work is not duplicated between the two systems, and that no parts of the work fail to be done because of mistaken assumptions that it would be done on the other system.

One possible approach to the problem of linking to closed, soon to be blocked, trials is to publish links that contain two link values. For example, we could add a new attribute "CTGovID" containing a link to a document on the NLM website:

<ProtocolRef cdr:href='123456' CTGovID='NCT9876543'>...</ProtocolRef>

Or perhaps with two additional IDs:

<ProtocolRef cdr:href='123456' CTGovID='NCT09876543', OtherID='COG-AAML0531'>
  ...
</ProtocolRef>

Bob, Blair and I discussed this. An advantage of this is that it avoids republishing a Summary solely because a Protocol referenced by the trial has changed status, which would increase the total CDR publishing + Gatekeeper processing time if we had to do it.

I confirmed that the summary we were using to test yesterday afternoon on Blair's VM (CDR256691) really does link to trials whose documents are no longer on the web site, and I confirmed that the summary document not only passes both schema and link validation, but also could be saved as a publishable version. However, it fails publication:

• ProtocolRef (CDR77026) Publishable Version of linked Document does not exist.

• ProtocolRef (CDR450908) Publishable Version of linked Document does not exist.

• ... [lots more] ...

So on our end, we need to:

• add the NCT ID to the linking elements in the schema and in the documents

• modify the publishing filter and the DTD to included the NCT ID

• modify the publishing software so that it doesn't block publication for ProtocolRef elements linking to blocked documents

Although Alan said in the original ticket description that other document types than Summaries, Margaret says that only summaries have ProtocolRefs that end up getting published.

~volker: It occurs to me that we have a couple of ways to approach this. One is to do everything in the denormalization filter, as we discussed yesterday. The other is to have that filter go find the NCT ID and pop it in place, and defer the work of dropping the ProtocolRef markup for the cases where there is no NCT ID until later on in the vendor output filter. Your thoughts?

I don't think I understand all of the things that need to be done. I thought the ProtocolRef markup has to stay in order to create a link to CT.gov?
Anyway, if links need to be removed it would fit better in the Vendor Cleanup Filter at the end, so the second option sounds to follow our setup a little better.

I thought the ProtocolRef markup has to stay in order to create a link to CT.gov?

That's true for most of them, but if there is no NCT ID, we have been asked to drop the ProtocolRef markup.

Ready for QA.

How do you suggest we test this? I assume we have to wait until the changes that need to happen on the Cancer.gov side is completed?

How do you suggest we test this?

Sorry it's taken so long to take care of this, William. When I got back to my desk after the CDR status meeting, my computer was frozen, and I lost the work I was in the middle of for tracking down a suitable summary and publishing it, and other things took over. I've been working on it this morning, but after exporting the document the push job failed because there's already a push job pending. When I finally get it pushed, you'll be able to look at CDR62759, which has a bunch of ProtocolRefs, some for CTGovProtocol documents, and some for InScopeProtocol documents. The only protocol whose CDR document is active is 706698. For that one, you should be linked to the CTGov Protocol page on the (QA) cancer.gov site. For all the rest, you should get the ClinicalTrials.gov page.

~volker: it looks like job 12664 finished pushing last night at 7:45, and it's still waiting for verification from GateKeeper. Can you look into what might be holding it up? Thanks!

I've updated the status for the push job. You can now submit another publishing job.

Thanks, Volker. I was able to push the summary to gatekeeper-qa successfully, and it's on the QA web site:

http://www-qa.cancer.gov/types/cervical/hp/cervical-treatment-pdq#section/all

~oseipokuw: You should be able to follow the links for protocols and end up on ClinicalTrials.gov if the protocol isn't on our own web site (which it won't be except for CDR706698: the "OUTBACK" trial – search for the text "The addition of adjuvant chemotherapy following chemoradiation therapy is currently being evaluated as part of a large multinational clinical trial.").

I have been testing this and so far I haven't found any problem. Hopefully, the select summary is not representative of all the summaries with protocol refs as this one has so many links to InScope trials that are closed and completed and for which we may have to create external refs to clinicaltrials.gov or remove the links altogether.

You won't have to create external refs for those links: the ProtocolRef element sent to cancer.gov has the nct_id attribute, and cancer.gov is able to take you to NLM's site when you click on the link.

Unfortunately, I have looked at least 3 of the InScope trials that did not have NCT IDs in their set of IDs. So I assume these won't have links created for them unless we add the NCT IDS to the InScope trials, is that right?

You won't have to create external refs for those links: the ProtocolRef element sent to cancer.gov has the nct_id attribute, and cancer.gov is able to take you to NLM's site when you click on the link.

I assume if Cancer.gov is able to create links to NLM for them, it should be reflected currently in the document I am reviewing on the test site? That is, I should expect the links to be live now on the test site.

Yes, if an InScopeProtocol does not have an OtherID/IDString element whose sibling OtherID/IDType element has the value "ClinicalTrials.gov ID" then we won't include an nct_id attribute on the exported ProtocolRef element.

Only for CDR62759, which is the only document I've pushed to the QA site.

That is right. It is the only summary document I am currently reviewing. So, it looks like the problem is that some of the InScope trials don't have NCT IDs.

I did some more testing and I have attached a spreadsheet with the trials I reviewed.

To summarize, we have quite a number of links to InScope trials that:
i. are currently closed or completed
ii. were never registered with clinicaltrials.gov
iii. and appear not to exist on clinicaltrials.gov currently (using IDs only to search)
iv. they have all been marked as "Transfer not required" with a comment of "Never registered in CTGov"

So, it looks like we can eliminate these InScope trials that are currently closed or completed since we do not have CTRP equivalents for them and they don't exist on clinicaltrials.gov. Maybe a global would be helpful since they have clearly been marked in the InScope protocol documents. Users may still have to go into the summaries to reword or cleanup some of the text around those links.

If you'd want me to do more testing you can publish these summaries on QA for me to review. They have a lot more Protocol Refs:
62923
62787

Would it be possible to publish these two summaries William suggested to the QA site? I would like to take a look at this too and I figure it would make sense for me to look at a different summary. Thanks.

I've started a hot-fix for those documents.

Just wanted to clarify that sometime next week would be fine - since this is already on QA, we'll be looking at this during the CA period.

Verified on PROD.