Closed malachig closed 6 years ago
I will look into 1) 2) This is different than what was discussed previously. I remember that we specifically changed it so that multiple ACMG codes of the same code could be assigned to the same assertion. I think this was based on Table 5 here: https://www.acmg.net/docs/Standards_Guidelines_for_the_Interpretation_of_Sequence_Variants.pdf.
Yeah I believe this was a slight misinterpretation. Though I agree there is some ambiguity here. When they say things like "≥2 Supporting (PP1–PP5)". They mean something like PP1+PP2. NOT PP1+PP1.
I think the reason for this is so that the requirement of orthogonal lines of evidence is built into the rubric. If an algorithm predicts a variant is pathogenic (PP3) you can assign that code. If ten algorithms predict pathogenicity, you still only get to count PP3 once. To get to a final call of pathogenic, you need some other kind of evidence (functional, inheritance patterns, etc.).
From the guidelines this is specifically stated: "Because many in silico algorithms use the same or very similar input for their predictions, each algorithm should not be counted as an independent criterion. PP3 can be used only once in any evaluation of a variant."
For most the other codes, this is not spelled out, but the way the assessment of the code is described you only assign it one time, based on a body of evidence. Multiple sources may collectively support that code, but in the final assessment you only get to count it once.
There are other codes such as PP1 (cosegration in a family) where it seems like you might want to count the evidence multiple times (e.g. three independent families with the same variant segregating with disease). However, the intent is that you would modify the strength of the one code rather than counting it more than once. e.g. PP1_moderate or PP1_strong (instead of the default level of _supporting).
In the ClinGen Variant Curation Interface I believe this is represented clearly. All codes are displayed for a variant. Each is either checked (Met) or not.
@malachig You should now be able to edit the ACMG codes. However, you won't be able to deduplicate the list of ACMG codes. The framework for submitting suggested changes will dedup any lists (both the old and the new) behind the scenes before submission and fail if the new and old lists are identical. In your case this would happen and you would get a "new attribute is the same as the old attribute" error. You could try to edit the assertion in the admin console. In this new release we also added some functionality so that you won't be able to submit duplicate acmg codes when creating an assertion.
It doesn't seem possible to fix this assertion in the admin console. There I just see an enumerated list of ACMG codes where each can be selected or not...
I was able to fix this by using the admin interface, clearing the existing codes, and then updating to the correct list.
Looks like this has been solved.
Two things that are somewhat urgent:
I am getting an error when I try to do this: