Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide a warning to user or admin about possible repeat entries #124

Closed
kkrysiak opened this issue Jun 2, 2015 · 7 comments
Closed

Provide a warning to user or admin about possible repeat entries #124

kkrysiak opened this issue Jun 2, 2015 · 7 comments

Comments

@kkrysiak
Copy link
Contributor

kkrysiak commented Jun 2, 2015

I almost entered a repeat entry today (DNAJB1-PRKACA) because I didn't realize someone else had beaten me to it. Currently, this is an admin task to clean up such events but without looking at the entries for a given variant, this is not evident in the admin interface. If we could automatically run a check for any evidence that matches "Evidence Type," "Pubmed ID" and "Variant" I think it would be very helpful. I can see this being handled in 2 ways. 1) A very simple warning in the admin interface indicating a possible repeat entry so we can compare and handle it appropriately. 2) A warning in the user interface displaying the existing entry that may conflict and a sort of "are you sure you want to submit?" interface. Something like two buttons indicating "submit, this is a unique entry" or "nevermind, this is a repeat" so the user can decide.

@malachig
Copy link
Member

malachig commented Jun 2, 2015

This sounds similar/related to this issue perhaps:
griffithlab/civic-server#58

@jmcmichael
Copy link
Contributor

As I understand it, griffithlab/civic-server#58 only applies to new suggested revisions from edit forms, and not new evidence items from the add evidence form. I definitely think it would be helpful to add the feature described by @kkrysiak above, and have given it some thought.

On the add evidence form, as soon as the form gets the gene, variant, and pubmed id, it can query the server to see if there are any matching entries, and then display them to the user as a small warning somewhere on the form - something like, "NOTE: [Existing/Pending] submissions exist for [gene][variant][evidence]. Please review the existing record here (link) to ensure that you intended submission is sufficiently unique to warrant its inclusion."

@kkrysiak
Copy link
Contributor Author

kkrysiak commented Jun 2, 2015

@jmcmichael, my concern with using gene, variant and pubmed id is that a single pubmed source can provide multiple lines of different types of evidence for a given variant (diagnostic - associated with X disease; prognostic - associated with poor survival), which is why I was recommending the inclusion of evidence type. Admittedly, I don't know how often that has happened in the data we have at this point.

@malachig
Copy link
Member

malachig commented Jun 2, 2015

I definitely like the idea of seeing a list of possibly similar items for the user to review. For multiple entries coming from the same source publication this could really help you to think about how to frame each of them (in addition to helping to avoid duplication).

@kkrysiak
Copy link
Contributor Author

kkrysiak commented Jun 3, 2015

With that in mind, sticking with gene, variant and pubmed ID for a comparator is perfect. It would just need to support multiple entries in an easily understood way for the user.

@kkrysiak
Copy link
Contributor Author

It might be time to resurrect this discussion. It's officially happened. 2 evidence items EID774 and EID1129 were submitted and moderated by completely non-overlapping CIViC users, providing evidence from the same manuscript.

@jmcmichael
Copy link
Contributor

OK, I believe this is doable on the client w/o requiring anything additional on the server. I'll go ahead and put a 'high priority' label on it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants