ifokkema
commented
2 years ago Most things are handled now. Leaving this open so remind us that some variants are still not handled properly, but continuing with other work now.
Open ifokkema opened 2 years ago
ifokkema
commented
2 years ago Most things are handled now. Leaving this open so remind us that some variants are still not handled properly, but continuing with other work now.
There are some issues with the current version of
lovd_fixHGVS()as in theimprove/getVariantInfobranch. These are mostly variants that are "fixed" in a wrong way, causing data loss. Especially when the result is valid HGVS, this can cause a big problem as the "corrected" variant can be used to overwrite the original variant.Variants that are edited but don't produce correct results
Variants that are left as HGVS (the most dangerous category):
[x]
c.361A>T^362C>Gtoc.361A>T(solution for now it to just return variants with a^)Variants that are left as sort-of HGVS:
[ ]
g.(?_102471082?_103268232_?)duptog.(?)It should be clear thatlovd_fixHGVS()can not fix this variant. When the center?is removed, the variant remains untouched.[x]
g.117232272AA>Gtog.117232272delinsGThis variant is then reported to need to be a substitution, whichlovd_fixHGVS()cannot fix. However, it's simply not translated correctly, it needs to becomeg.117232272_117232273delinsGor we should choose not to change it out of fear of ambiguity.[x]
g.(135782758_135785957)_(135766735_?)deltog.(135766735_135785957)_(135782758_?)delStill not HGVS (positions still not in the right order), but I don't think we should have touched the positions at all.[ ]
g.(150138199_150142492)_(150145873_15147218)deltog.(15147218_150142492)_(150138199_150145873)delPositions are still not in the right order, but the last position misses a "0" in the description. I'm not super comfortable ignoring this issue even though the positions are still not in the right order, so the result is not HGVS.[x]
g.(71706000_71841092)_(71841092_71841092)duptog.(71706000_71841092)_71841092dupI'm not entirely sure how to interpret this variant, but I suppose we're almost there, but not quite.Variants that are destroyed due to a bug (code generates a lot of notices):
[x]
c.-104-90_-104-899insAAAAA=>c.Note that the actual issue is a typo in the first position.[x]
c.(?_-1)_(-1_?)dup=>c.I believe, technically, this is correct HGVS, so a fix may be required inlovd_getVariantInfo()for this. Related isc.(?_-182)_(-182_59)del. The problem appears to be that the inner position are equal. I suspect a simple<should be changed to<=or so.[x]
g.(31196786_3119694)?=>g.I'm not sure if this is HGVS.Small errors:
[x]
c.145+1_146-1::NM_032221.4:c.(-24+1_-23-1)toc.145+1_146-1::NM_032221.4:(-24+1_-23-1)Second prefix is removed.[x]
g.(135100001_136800000)_qterdelins[NC_000020.10:g.pter_(5100001_17900000)inv]tog.(135100001_136800000)_qterdelins[NC_000020.10:pter_(5100001_17900000)inv]Second prefix is removed.[x]
c.1537-?_2784+?delins(1757-?)_(2611)toc.1537-?_2784+?delins(1757-?)_N[2611]Last position is misinterpreted as an insertion of 2611 bases.[x]
C.3242C>Atog.C.3242C>A[ ]
del ex4tog.delex4[ ]
GRCh37 chr17:g.47332514_49565743deltog.GRCh37chr17:47332514_49565743del[x]
:g.220290456C>Ttog.:220290456C>TStuff we could learn to fix but is currently left unchanged:
[x]
g.6128749_6128787delins[NC_000022.11:17178886_17178924](misses prefix in inserted sequence)[ ]
g.(7045869_7045967)[ins15](rewrite intoinsN[15])[x]
g.8701170T>.(rewrite to del)Other:
[x] Now that we have
lovd_getVariantLength(), we could implement this and check the suffixes. So, not just delete the suffix for variants likec.1delAA, as obviously the length doesn't match the positions.