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.

Sign up for GitHub

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

Jump to bottom

Collecting recently failed variants as a list. please add #545

Open
Peter-J-Freeman opened this issue Sep 13, 2023 · 152 comments
Open

Collecting recently failed variants as a list. please add #545

Peter-J-Freeman opened this issue Sep 13, 2023 · 152 comments

Comments

@Peter-J-Freeman
Copy link
Collaborator

chr5:112839840_112839842delGGCinsTGA b38
@Peter-J-Freeman
Copy link
Collaborator Author

Peter-J-Freeman commented Sep 13, 2023 •
edited
Loading

19-40397933-ATCT-A b38
11-118505219-TTC-T b38
'5-177248182-G-A b38
chr10:g.102360218C>G b38

All seem to be the same error

Traceback (most recent call last):
File "/local/miniconda3/envs/vvweb_v2/lib/python3.10/site-packages/VariantValidator/modules/vvMixinCore.py", line 739, in validate
toskip = self._get_transcript_info(my_variant)
File "/local/miniconda3/envs/vvweb_v2/lib/python3.10/site-packages/VariantValidator/modules/vvMixinCore.py", line 1611, in _get_transcript_info
variant.gene_symbol = entry['hgnc_symbol']

NOTE: These are now fixed

@leicray
Copy link
Contributor

leicray commented Oct 9, 2023 •
edited by Peter-J-Freeman
Loading

The attached text file contains a long list of variants that have triggered ERROR messages from the interactive validation tool since the start of September this year.

Some of these might now be handled correctly since the recent patches.

variants that trigger error messages.txt

GRCh37 variants fixed

@leicray
Copy link
Contributor

leicray commented Oct 9, 2023

It looks like a user is trying to validate NM_024496.4:c.369_374del which does validate correctly in the interactive tool.

However, the error message says:

Internal Server Error: /bed/

TypeError at /bed/
create_bed_file() missing 5 required positional arguments: 'chromosome', 'build', 'genomic', 'vcf', and 'version'

That looks like the vcf2hgvs tool is being used. However, that would require the user to place the variant in a text file and then upload that file to the vcf2hgvs tool. Possible, but unlikely.

@Peter-J-Freeman
Copy link
Collaborator Author

Variant: 1-156138613-C-T

Hello, I'm having a problem validating the synonymous variant in LMNA (ClinVar ID 14500) - NM_170707.4(LMNA):c.1824C>T p.(Gly608=). I tried different ways, including chr1(GRCh38):g.156138613C>T and 1-156138613-C-T. Message error: Unable to validate the submitted variant against the GRCh38 assembly Thank you in advance.

@Peter-J-Freeman
Copy link
Collaborator Author

It looks like a user is trying to validate NM_024496.4:c.369_374del which does validate correctly in the interactive tool.

However, the error message says:

Internal Server Error: /bed/

TypeError at /bed/
create_bed_file() missing 5 required positional arguments: 'chromosome', 'build', 'genomic', 'vcf', and 'version'

That looks like the vcf2hgvs tool is being used. However, that would require the user to place the variant in a text file and then upload that file to the vcf2hgvs tool. Possible, but unlikely.

This is the code trying to create a UCSC link I believe. Not VCF. Thanks for logging it

@leicray
Copy link
Contributor

leicray commented Oct 31, 2023

Here is another one that ought not to trip up the system: NM_000179.3:c.4083dup

It generates error messages from the interactive service and submission to the batch tools also fails. The reference sequence is the MANE Select transcript for the MSH6 gene.

The traceback message for failure to validate via the batch tool is:

Traceback (most recent call last):
File "/local/py3Repos/variantValidator/VariantValidator/modules/vvMixinCore.py", line 752, in validate
toskip = mappers.transcripts_to_gene(my_variant, self, select_transcripts_dict_plus_version)
File "/local/py3Repos/variantValidator/VariantValidator/modules/mappers.py", line 643, in transcripts_to_gene
protein_dict = validator.myc_to_p(hgvs_coding, variant.evm, re_to_p=False, hn=variant.hn)
File "/local/py3Repos/variantValidator/VariantValidator/modules/vvMixinInit.py", line 535, in myc_to_p
start_aa = utils.one_to_three(aa_seq[0])
IndexError: string index out of range

In addition, this triggers a further exception:

Traceback (most recent call last):
File "/local/miniconda3/envs/vvweb_v2/lib/python3.10/site-packages/celery/app/trace.py", line 412, in trace_task
R = retval = fun(*args, **kwargs)
File "/local/miniconda3/envs/vvweb_v2/lib/python3.10/site-packages/celery/app/trace.py", line 704, in protected_call
return self.run(*args, **kwargs)
File "/local/VVweb/web/tasks.py", line 60, in batch_validate
output = validator.validate(variant, genome, transcripts)
File "/local/py3Repos/variantValidator/VariantValidator/modules/vvMixinCore.py", line 1462, in validate
raise fn.VariantValidatorError('Validation error')
VariantValidator.modules.utils.VariantValidatorError: Validation error

@Peter-J-Freeman
Copy link
Collaborator Author

Peter-J-Freeman commented Oct 31, 2023 via email

@leicray
Copy link
Contributor

leicray commented Oct 31, 2023

What do you mean by "add it"? This is the report.

@Peter-J-Freeman
Copy link
Collaborator Author

Peter-J-Freeman commented Oct 31, 2023 via email

@leicray
Copy link
Contributor

leicray commented Nov 1, 2023

Here is another one that trips up the interactive and batch validators:

11:2587692del (GRCh38)

@Peter-J-Freeman
Copy link
Collaborator Author

Thanks @leicray . Realised its a git email this time. I'm gonna do a little debugging now. Need time away from grant writing

@leicray
Copy link
Contributor

leicray commented Nov 2, 2023

And another one:

chr5:g.125887814C>T (GRCh37)

@Peter-J-Freeman
Copy link
Collaborator Author

Will come back to this one NG_059281.1:g.4962G>C (GRCh38). It's a database issue. Missing records

@Peter-J-Freeman
Copy link
Collaborator Author

This one too NG_061374.1:g.11229T>C (b38)

@Peter-J-Freeman
Copy link
Collaborator Author

So, the issue was that RefSeq are not maintaining RefSeqGene lookup tables. I added code to get the data from the API on fails. These variants are not fixed, but will not be fixed live until I do a new database build

@Peter-J-Freeman
Copy link
Collaborator Author

or at least do a interim update on the live servers which may be quicker for now.

@Peter-J-Freeman
Copy link
Collaborator Author

Here is another one that trips up the interactive and batch validators:

11:2587692del (GRCh38)

I don't know if I have the words.

@leicray
Copy link
Contributor

leicray commented Nov 2, 2023

I did wonder about that one. However, there is a genome build provided, a chromosome, a nucleotide number, and the nature of the change to that nucleotide. In a sense, it's little different from chr17:50198002C>A. What am I missing?

@Peter-J-Freeman
Copy link
Collaborator Author

It's not that sample sadly. I will need to figure out where to pus a Regex to catch it. I'm sure it'll fit. Hopefully with the code that allows chr17:50198002C>A. The difference is that chr17:50198002C>A is derived as art of pseudo VCF re-formatting. The description 11:2587692del is a bit different because 50198002C>A comes from 50198002:C:A. 11:2587692del should be derived from somethign like 50198002:CC:C not "del". Hopefully its a quick tweak though. Fun times! At least you came up with a reasonable explanation as to where the description came from

@Peter-J-Freeman
Copy link
Collaborator Author

NC_000023.11:r.650_831del

@leicray
Copy link
Contributor

leicray commented Jan 17, 2024

chr11:g,108121787G>A GRCh37

The anonymous submitter also tried GRCh38 and that failed too, of course.

This should be easy to trap and correct as the comma just needs to be replaced by a full stop.

@Peter-J-Freeman
Copy link
Collaborator Author

Will get this one done asap. Easy one hopefully

@leicray
Copy link
Contributor

leicray commented Jan 23, 2024

An anonymous user has tried to validate LRG_199p1:p.? and it has failed, generating an error message.

If I rewrite the variant description as LRG_199p1:p.Met1Ala I receive the expected warnings:

- LRG_199p1:p.Met1Ala automapped to equivalent RefSeq record NP_003997.1:p.Met1Ala

- Protein level variant descriptions are not fully supported due to redundancy in the genetic code

- NP_003997.1:p.Met1Ala is HGVS compliant and contains a valid reference amino acid description

Ought to be easy to trap.

@ifokkema
Copy link
Collaborator

If I rewrite the variant description as LRG_199p1:p.Met1Ala I receive the expected warnings:

I might be wrong, but are you suggesting that is valid syntax? Because a change to the first codon leads to an unpredictable result. The docs say:

Do not use descriptions like "p.Met1Thr", this is for sure not the consequence of the effect on protein translation.

(source)

@leicray
Copy link
Contributor

leicray commented Jan 23, 2024

You are quite correct. I simply wanted generate a variant description that would not cause the validator to fall over. I have no idea what comes next after Met1 in the DMD protein sequence, so pushed on with that.

Of course, there ought to be an additional warning that p.Met1Ala is not valid and ought to be written as p.(Met1?). Even that might be wrong.

@Peter-J-Freeman
Copy link
Collaborator Author

This should be triggering the warning and I wonder if it is trying to and failing. Will look into it

@ifokkema
Copy link
Collaborator

You are quite correct. I simply wanted generate a variant description that would not cause the validator to fall over. I have no idea what comes next after Met1 in the DMD protein sequence, so pushed on with that.

Ah, OK, you were just testing the reference sequence 😅 Never mind me!

@Peter-J-Freeman
Copy link
Collaborator Author

I'm still worried that the Met1 warning wasn't generated. So 2 fixes here. A chance to increase code coverage :P

@Peter-J-Freeman
Copy link
Collaborator Author

@leicray @ifokkema. Ok, here I put a spanner in the works. p.Met1Ala could actually be correct wheres p.(Met1Ala) would be p.(Met1?)

@ifokkema
Copy link
Collaborator

Hmm... I don't think that has ever been observed in humans... ClinVar reports this variant, but ClinVar always lies when it comes to protein descriptions 🙄
Are you thinking of ever providing full protein description validation? If not, I would personally ignore the near-zero chance of any substitution in the Met1 codon. While translation has been proven to sometimes start at non-CTG start codons, we're actually talking about the situation where a canonical transcript by default started with ATG but now also tolerates a non-ATG start induced by a variant. CTG being the most common non-ATG start codon, in theory, a p.Met1Leu could occur. Googling around allowed me to find one paper mentioning this, but at the same time, the variant also lowered translation considerably, so even then, p.Met1Leu wouldn't actually be the correct description.

@Peter-J-Freeman
Copy link
Collaborator Author

how about this?

{
    "flag": "warning",
    "metadata": {
        "variantvalidator_hgvs_version": "2.2.0",
        "variantvalidator_version": "2.2.1.dev729+g86e62d8.d20241105",
        "vvdb_version": "vvdb_2024_8",
        "vvseqrepo_db": "VV_SR_2024_09/master",
        "vvta_version": "vvta_2024_09"
    },
    "validation_warning_1": {
        "alt_genomic_loci": [],
        "annotations": {},
        "gene_ids": {},
        "gene_symbol": "",
        "genome_context_intronic_sequence": "",
        "hgvs_lrg_transcript_variant": "",
        "hgvs_lrg_variant": "",
        "hgvs_predicted_protein_consequence": {
            "lrg_slr": "",
            "lrg_tlr": "",
            "slr": "",
            "tlr": ""
        },
        "hgvs_refseqgene_variant": "",
        "hgvs_transcript_variant": "",
        "primary_assembly_loci": {},
        "reference_sequence_records": "",
        "refseqgene_context_intronic_sequence": "",
        "rna_variant_descriptions": null,
        "selected_assembly": "GRCh38",
        "submitted_variant": "NM_000179.3:r.3646_3646+1insugagauaugcauag",
        "transcript_description": "",
        "validation_warnings": [
            "VariantSyntaxError: RNA (r.) reference sequences do not contain introns. Intronic descriptions are described in the context of a c. description"
        ],
        "variant_exonic_positions": null
    }
}

Also @leicray can you comment on this issue so we can mark it as completed and update the text as necessary

#545 (comment)

@ifokkema
Copy link
Collaborator

Related information:

  • The HVNC only relatively recently concluded that intronic sequences are not part of the RNA molecule, even though examples on the website still list this, e.g., r.2949_2950ins[2950-30_2950-12;uuag]. We are currently deciding what the correct syntax would be. Likely, this will be r.2949_2950ins[c.2950-30_2950-12;uuag] (note the addition of "c.".
  • Related; recently Alex noticed that the IUPAC nucleotide codes for RNA are actually now ACTG and not acug. Therefore, likely, soon the HVNC will vote on changing the recommendations, which will then turn the example above into r.2949_2950ins[c.2950-30_2950-12;TTAG]. Nothing is final yet, but so far, nobody opposes the idea. This will also affect VariantValidator, so I thought to give you a heads-up.

@leicray
Copy link
Contributor

leicray commented Nov 26, 2024

I would change the second part of the warning to read: Variant descriptions containing intronic locations are only valid in the context of a c. description.

@Peter-J-Freeman
Copy link
Collaborator Author

thanks @leicray . Done.

@ifokkema. thanks for the heads up. Reomving the lowercase and u will be an easy job and will reduce the amount of processing. We will need to, however, uppercase and convert U > T.

This seems like a strange decisision by IUPAC. please let us know when the HGVS votes on this

@ifokkema
Copy link
Collaborator

@ifokkema. thanks for the heads up. Reomving the lowercase and u will be an easy job and will reduce the amount of processing. We will need to, however, uppercase and convert U > T.

This seems like a strange decisision by IUPAC. please let us know when the HGVS votes on this

I honestly don't know when IUPAC made this change, but a quick check online doesn't show me any pages still using the old nomenclature. So it's probably been a while. I'll keep you updated on the vote!

@leicray
Copy link
Contributor

leicray commented Nov 28, 2024

A user submitted the incorrect variant description NM_000314.8:c.(209+1_254-1)del five times. When the unnecessary brackets are removed, the variant validates correctly. Can the initial parsing step be adapted to sort the rogue brackets and post a warning message?

Peter-J-Freeman added a commit that referenced this issue Dec 2, 2024
@Peter-J-Freeman
code changes that refer to issue #651 variants with N in the referenc…
6340024 
…e and intrins in r. descriptions as referred to in #545
@ifokkema
Copy link
Collaborator

ifokkema commented Dec 2, 2024

A user submitted the incorrect variant description NM_000314.8:c.(209+1_254-1)del five times. When the unnecessary brackets are removed, the variant validates correctly. Can the initial parsing step be adapted to sort the rogue brackets and post a warning message?

I doubt NM_000314.8:c.209+1_254-1del, a simple omission of the parentheses, was meant. More likely, NM_000314.8:c.(209+1_210-1)_(253+1_254-1)del was meant, or in the old notation, NM_000314.8:c.210-?_253+?del. I understand that probably, the best interpretation for this to be validated on the sequence level is indeed just to drop the parentheses, I don't think VV should return NM_000314.8:c.209+1_254-1del as the "fixed" variant.

@leicray
Copy link
Contributor

leicray commented Dec 2, 2024

I agree with everything that you say regarding NM_000314.8:c.209+1_254-1del but it's impossible to know what was actually in the mind of the user.

I always try to respond to user "errors" such as this if the user has logged in so that I can figure out their email address from their login ID. I did that in this case too and asked the user to get back to me with more info. I have received no reply and that's what happens in the majority of cases. Most users are rather unthinking (rude) when invited to respond.

@leicray
Copy link
Contributor

leicray commented Dec 5, 2024

A user has tried unsuccessfully (and three times to validate the variant description NP_000483.3:c.579+3A>G. Initial parsing of this variant ought to notice the NP_/c. mismatch and generate a warning to the user.

@ifokkema
Copy link
Collaborator

ifokkema commented Dec 5, 2024

A user has tried unsuccessfully (and three times to validate the variant description NP_000483.3:c.579+3A>G.

The dev version of the LOVD HGVS syntax checker says: "Protein reference sequences are not supported. Please submit a DNA variant using a DNA reference sequence."

@Peter-J-Freeman
Copy link
Collaborator Author

I have added the following

import json
import VariantValidator
vval = VariantValidator.Validator()
variant = 'NP_000483.3:c.579+3A>G.'
genome_build = 'GRCh38'
select_transcripts = 'all'
validate = vval.validate(variant, genome_build, select_transcripts)
validation = validate.format_as_dict(with_meta=True)
print(json.dumps(validation, sort_keys=True, indent=4, separators=(',', ': ')))

{
    "flag": "warning",
    "metadata": {
        "variantvalidator_hgvs_version": "2.2.0",
        "variantvalidator_version": "2.2.1.dev709+g6340024",
        "vvdb_version": "vvdb_2024_8",
        "vvseqrepo_db": "VV_SR_2024_09/master",
        "vvta_version": "vvta_2024_09"
    },
    "validation_warning_1": {
        "alt_genomic_loci": [],
        "annotations": {},
        "gene_ids": {},
        "gene_symbol": "",
        "genome_context_intronic_sequence": "",
        "hgvs_lrg_transcript_variant": "",
        "hgvs_lrg_variant": "",
        "hgvs_predicted_protein_consequence": {
            "lrg_slr": "",
            "lrg_tlr": "",
            "slr": "",
            "tlr": ""
        },
        "hgvs_refseqgene_variant": "",
        "hgvs_transcript_variant": "",
        "primary_assembly_loci": {},
        "reference_sequence_records": "",
        "refseqgene_context_intronic_sequence": "",
        "rna_variant_descriptions": null,
        "selected_assembly": "GRCh38",
        "submitted_variant": "NP_000483.3:c.579+3A>G.",
        "transcript_description": "",
        "validation_warnings": [
            "Protein reference sequence input as Nucleotide (:c.) variant."
        ],
        "variant_exonic_positions": null
    }
}

Will work for both NP_ and ENSP and with variant types g. c. r. n.

@ifokkema not ignoring your email about requests for the LOVD API. We need to meet up and discuss integration with you

@leicray
Copy link
Contributor

leicray commented Dec 9, 2024

This is not a "failed variant" issue but it probably belongs here anyway as it's an input-parsing issue of a sort.

An anonymous user has twice tried to search for transcripts for a gene using the HGNC gene ID. The first submitted 7491 and then tried HGNC:7419. The gene2trans tool is supposed to accept HGNC gene IDs. The 7491 ID corresponds to the mitochondrial gene MT-CO1. Could that be the basis of the problem?

@leicray
Copy link
Contributor

leicray commented Dec 9, 2024

An anonymous user has twice tried to validate the variant description RAD51C:c.(404+1_405-1)_(571+1_572-1)del which failed on both occasions. To compound the issue, the user specified NM_58216 as the transcript for reporting. The MANE Select transcript for the RAD51C gene is NM_058216.3.

This looks like a failure to properly parse the input.

@leicray
Copy link
Contributor

leicray commented Dec 19, 2024

An anonymous user has tried to validate the variant description DNA(B)-CALR-gen (LRG_828t1:c.1054_1254). There is so much wrong here that I do not know where to begin.

This looks like a failure to properly parse the input.

@leicray
Copy link
Contributor

leicray commented Jan 2, 2025

A user has submitted the variant description NM_001613.4:r.3646_3647insuaaaauaugcauaaggaaguaacucaaacag which triggers an ERROR message.

The basic problem is that position 3646_3647 is out of range for transcript NM_001613.4. It ought to be possible to trap errors of this type and provide a helpful warning message to the user.

@leicray
Copy link
Contributor

leicray commented Jan 8, 2025

An anonymous user tried to validate the variant description NC_000020.10(RTEL1):g.62305406_62305482delN[77]insN[168] which failed, creating an ERROR message.

If corrected to NC_000020.10:g.62305406_62305482delinsN[168], the variant validates.

The gene symbol is redundant, as is the number and "identity" of the deleted nucleotides.

@leicray
Copy link
Contributor

leicray commented Feb 4, 2025

An anonymous user's submission generated these ERROR message lines:

POST:
variant = '105'
transcripts = 'NM_033116.6:c.G1715T:p.G572V'
genomebuild = 'GRCh37'
pdf_request = 'False'
refsource = 'refseq'

So much wrong here. The irony is that the corrected description, NM_033116.6:c.1715G>T, does validate and yields the protein-level variant p.(G572V).

@ifokkema
Copy link
Collaborator

ifokkema commented Feb 4, 2025

Hmm... what do you think the user meant with "105"? For what it's worth, my HGVS library responds to NM_033116.6:c.G1715T:p.G572V with:

  • This is not a valid HGVS description. Did you mean to write a substitution?
  • We stopped reading past "NM_033116.6:c.G1715T". We could not interpret ":p.G572V".
  • Suggested fix: NM_033116.6:c.1715G>T, 100% confidence.

@leicray
Copy link
Contributor

leicray commented Feb 4, 2025

I see LOTS of failed validation requests for which the submitted variant description is simply a long numeric string. By comparison "105" is modestly short.

I really have no idea why users are doing this. I can only reply to registered users to offer help and to ask what they were trying to do, but none have ever replied with respect to this type of error.

@ifokkema
Copy link
Collaborator

ifokkema commented Feb 4, 2025

I also see no link between "105" and the gene (NEK9).

Is the use of a variant description in the "transcripts" field common enough to add some code that checks that, perhaps only when the "variant" field itself can't be interpreted and tries to handle that?

@leicray
Copy link
Contributor

leicray commented Feb 4, 2025

I dot not commonly see users placing the variant description in the "transcripts" field. The most common error of this type is simply submitting a long numeric string with no pretence to it being a valid variant description.

I wonder occasionally if it's perhaps intended to be malicious in some way.

@ifokkema
Copy link
Collaborator

ifokkema commented Feb 4, 2025

That's definitely a possibility, although then I would expect attempts like SQL injection, XSS, local file inclusion, etc. We get those all the time, but they are mostly handled by the LOVD infrastructure before they reach the rest of the code, so they rarely get included in reports.

@leicray
Copy link
Contributor

leicray commented Feb 14, 2025

An anonymous user has twice submitted the variant description NG_008199.1:r.70370_70453del which triggered an ERROR message to the sysadmins. The on-screen error message is: Unable to validate the submitted variant NG_008199.1:r.70370_70453del against the GRCh38 assembly.

When the description is changed to NG_008199.1:g.70370_70453del it validates correctly.

@ifokkema
Copy link
Collaborator

An anonymous user has twice submitted the variant description NG_008199.1:r.70370_70453del which triggered an ERROR message to the sysadmins. The on-screen error message is: Unable to validate the submitted variant NG_008199.1:r.70370_70453del against the GRCh38 assembly.

When the description is changed to NG_008199.1:g.70370_70453del it validates correctly.

The LOVD/HGVS library returns, in this case: EWRONGREFERENCE: "The given reference sequence (NG_008199.1) does not match the RNA type (r). For r. variants, please use a transcript reference sequence."
It would probably be a good idea if we'd also suggest "g." as a fix, since the library fully knows that NGs require "g.". I'll add that to my to do, as it's indeed the most logical fix.

@leicray
Copy link
Contributor

leicray commented Feb 17, 2025

A user twice submitted the variant description LRG_672t1:c.195_*18del, failing validation on both occasions. The user had selected Ensembl as the reference source. Changing this to RefSeq allowed correct validation.

The submission form perhaps needs a guidance message about submitting LRG-based descriptions or needs to auto "correct" to RefSeq, if necessary, when LRG-based descriptions are submitted.

@leicray
Copy link
Contributor

leicray commented Feb 18, 2025

A user has submitted the variant description LRG_214t1:r.480_586dup for validation and the process failed. If the description is changed to LRG_214t1:c.480_586dup then validation completes.

The latter description is probably what was intended, but the original variant description ought to have validated successfully as there appear to be no obvious syntax errors. The only possible issue is that normalization pushes the duplication 2bp into an intron and that would not be possible for an "r." description.

Errors like this need to be better handled with a clearer error message.

@leicray
Copy link
Contributor

leicray commented Feb 25, 2025 •
edited
Loading

A user submitted the variant description NM_000344.4:c.(*3+1_*4-1)del which failed to validate. Removing the brackets to giveNM_000344.4:c.*3+1_*4-1del resulted in a valid description.

User errors like this need to be trapped and guidance be sent to the user.

EDIT: Three days later, an anonymous user submitted NM_000642.3:c.(3836+1_3837-1)del for validation, which failed. As before, removal of the brackets allowed the description to validate.

@leicray
Copy link
Contributor

leicray commented Mar 6, 2025

An anonymous user has submitted NM_007294.4:c.(4186-20_4357+187)dup three times and each attempt has failed. It works fine if the brackets are removed.

I'm not saying that just removing the brackets solves every issue with this description.

@ifokkema
Copy link
Collaborator

ifokkema commented Mar 6, 2025

This one is similar to the previous two. Whether this is valid or not depends; the HGVS guidelines are unclear about this. I had previously opened a discussion about it. Currently, Jeroen, Johan, and I have commented on it. If you have suggestions or recommendations, please add them there if you have time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@leicray @ifokkema @Peter-J-Freeman @John-F-Wagstaff