PubMed accept replaces files for VoR content that's upddated

[Melissa37]

Problem / Motivation

Until recently PubMed did not allow us to redeliver content to them via FTP once the content was published in VoR format. If production made any changes and published new versions the production staff update content on PubMed's site manually via the interface they provide for publishers.

It seems this has now changed and they can accept replaces files:

_Note: We accept Replaces files for ahead-of-print citations and for data in the following fields regardless of the citation’s status in PubMed:

AuthorList (includes Author, Affiliation, Identifier) InvestigatorList (includes Investigator, Affiliation, Identifier) Pagination ELocationID OtherAbstract PII DOI Our loader will compare the content of these fields in the Replaces file with the existing PubMed citation and only modify the content if it is different._

https://www.ncbi.nlm.nih.gov/books/NBK3828/#publisherhelp.Correcting_Errors_in_PubMe

Proposed solution

@gnott can we investigate automating the process so we send new versions to PubMed?

@eLifeProduction FYI

[gnott]

One part of code related to this would be the set_replaces() function in generate.py of PubMed deposit library: https://github.com/elifesciences/elife-pubmed-xml-generation/blob/develop/elifepubmed/generate.py#L410-L428

As I can remember and interpret, the <Replaces> tag will get added if an article version is greater than 1, or of the Article object is explicitly set as having replaces=True. The Article object can be populated in by the elife-bot (for how eLife has it integrated currently), although I've not checked whether that is the case.

The other spot eLife would need to check is in the elife-bot again in the ScheduleDownstream activity (https://github.com/elifesciences/elife-bot/blob/develop/activity/activity_ScheduleDownstream.py). Here I think all the VoR versions are already being sent again, but silent corrections are not sent again.

So, in summary, I think eLife is already sending new versions to PubMed again, but we are not sending any that are due to a silent correction. Would you want silent corrections of the most recent version of the article to be sent to Pubmed as well?

[Melissa37]

Thanks @gnott! I have sent PubMed an email to confirm what they will update automatically and will let you know what they say, now I have this info too :-)

M

[Melissa37]

@gnott

This was the response:

You are correct, in 2017 we began accepting replaces files for updates to these fields regardless of the citation status. The documentation below is correct regarding the fields that can be updated with a <Replaces> file vs. PMDM only.

[Melissa37]

OK to ignore silent corrections.

Need to check the logic of the workflow again.

If VoR 2 etc, can send to PubMed if replacing one of the items listed above

[gnott]

Acted on the idea we had on today's call, I found an article that has multiple VoR versions, e.g. article 50796. It was sent again today (2020-02-04) to PubMed. I found the batch file in the S3 bucket where such things are stored for reference, and the deposit includes:

<Replaces IdType="doi">10.7554/eLife.50796</Replaces>

I will conclude that regular VoR versions published that are greater than version 1 will include a <Replaces> tag in the article's PubMed deposit file. Most likely this also happens with any PoA that is version greater than 1.

So what I would expect is any of the fields that are updated by PubMed when there is a <Replaces> tag will be updated normally, and has been for some time in the past. The fields they do not automatically update will be ones Production may need to manually update with PubMed?

[gnott]

Is that all that can be answered here do you think @Melissa37, or do you have more questions I can help answer? I will bat the issue back to you!

[gnott]

One more note about silent corrections: I see nothing to stop PubMed deposits as a result of silent corrections of a VoR in the code. I think previously we (or I) depended on PubMed to reject later deposits of an article, even if it had a <Replaces> tag, so the PubMed record would not be altered as a result of a silent correction of a previous version.

We may want to guard against silent corrections of a version that is older than the most recent version from being deposited to PubMed. If so please confirm @Melissa37, and I'll create a new ticket to describe the logic for the elife-bot project.

[Melissa37]

I would like to exclude sending silent corrections to PubMed. I think it makes sense not to send them.

@eLifeProduction can we do a test: If you do a new version that changes one of these fields: Author name ORCID Author affiliation Digest

Please don't update PubMed using the publisher interface but wait a few days and check it has been done automatically.

Once we know that, we'll update the PubMed process documentation of what we have to update in the interface.

Cheers! M

[Melissa37]

@eLifeProduction Note - this excludes feature content as they tend to do silent corrections for any changes and so this won't be sent to PubMed and you'd need to update via the pubmed publisher interface

[gnott]

I would like to exclude sending silent corrections to PubMed. I think it makes sense not to send them.

I will prepare a PR into the elife-bot project to not do any PubMed deposits as a result of a silent correction workflow.

[Melissa37]

@eLifeProduction Have we had one of these situations yet?

[eLifeProduction]

55607 that was just issued by Naushin earlier today would be a good test case, I think?

(We're had a few since Feb, I'm sure, but I don't know the numbers off hand!)

Thanks,

James

[naushinthomson]

It looks like the affiliation was automatically updated in PubMed! Do you need any more info on this?

[Melissa37]

Thanks @naushinthomson !

@gnott we can close this ticket now?

Cheers M

[gnott]

Yes, I think we can close the issue, if I remember we wanted to confirm that particular data is getting updated automatically at PubMed when new article versions are published, and it is the case that the data is getting updated. It sounds like we're all satisifed with the explanation and the results. Thanks for all the input and checking the results in great detail!