[ensembl-dev] VEP ClinVar information
Guillermo Marco Puche
guillermo.marco at sistemasgenomicos.com
Mon Aug 17 12:09:33 BST 2015
Hi Will,
Awesome! ClinVar is so direct to check $tva->feature_seq with
$pf->risk_allele.
As you said, for other PhenotypeFeatures like OMIM there's no
risk_allele, allele_symbol or allele_accession_id.
*1 2228866 rs387907306 G A,T
*For this case I'm getting two OMIM phenotype features I can't "check"
if correct since risk_allele association provides the OMIM allelic
variant number*. *I guess then there's no way to associate OMIM
phenotype feature to a specific allele.
*
*
**# omim_feature: 1**
****phenotype_description: Shprintzen-Goldberg craniosynostosis syndrome
source_name: OMIM
external_reference: MIM:164780
is_significant: 1
variation allele: A
The risk allele is: 0004
****
**# omim_feature: 2**
****phenotype_description: Shprintzen-Goldberg craniosynostosis syndrome
source_name: OMIM
external_reference: MIM:164780
is_significant: 1
variation allele: A
The risk allele is: 0005
*# omim_feature: 1*
**phenotype_description: Shprintzen-Goldberg craniosynostosis syndrome
source_name: OMIM
external_reference: MIM:164780
is_significant: 1
variation allele: T
The risk allele is: 0004
**
*# omim_feature: 2*
**phenotype_description: Shprintzen-Goldberg craniosynostosis syndrome
source_name: OMIM
external_reference: MIM:164780
is_significant: 1
variation allele: T
The risk allele is: 0005
Regards,
Guillermo.
**
On 17/08/15 10:25, Will McLaren wrote:
> Hi Guillermo,
>
> The plugin run() sub-routine is executed for each allele + transcript
> combination; the object is a TranscriptVariationAllele, and you can
> find to which allele you are referring with either
> $tva->variation_feature_seq() or $tva->feature_seq(); these give you
> the allele relative to the input variant and transcript respectively
> (i.e. the two will differ if the transcript is on the reverse strand.
> See
> http://www.ensembl.org/info/docs/Doxygen/variation-api/classBio_1_1EnsEMBL_1_1Variation_1_1TranscriptVariationAllele.html
>
> The data you return from the run() sub will only appear in the block
> of output for that allele.
>
> If you are retrieving phenotype data from Ensembl, then you may find
> that we don't always have an allele-specific annotation stored. For
> some PhenotypeFeature objects, they will have an attribute
> "risk_allele", "allele_accession_id" or "allele_symbol", but many will
> not. You may also find that due to strand or reporting issues, the
> sequence in the associated allele may not match exactly one of the
> alleles from the VariationFeature or VCF.
>
> Regards
>
> Will
>
> On 14 August 2015 at 14:49, Guillermo Marco Puche
> <guillermo.marco at sistemasgenomicos.com
> <mailto:guillermo.marco at sistemasgenomicos.com>> wrote:
>
> Dear devs,
>
> I would like to know what's the correct way to handle information
> when multiple alleles appear in a VCF record.
>
> For example, Homo_sapiens_clinically_associated.vcf dataset:
>
> *1 2228866 rs387907306 G A,T*
>
> Each one of alternative alleles has different OMIM and Clinvar
> allele info.
>
> The plugin code is using the following scope:
>
> *sub feature_types {**
> ** return ['Transcript'];**
> **}
>
> *Is there another feature_type level like Transcript, Allele?*
> *
> I'm trying to solve it with the iteration code you provided me Will:
>
> * foreach my $known_var(@{$vf->{existing} || []}) {**
> ** foreach my
> $pf(@{$pfa->fetch_all_by_object_id($known_var->{variation_name})}){**
> ** #do_stuff**
> ** }**
> **}*
>
> However this is getting me the phenotype information for both
> alternative alleles (A and T) (transcript level) and this being
> wrote in output for every alternative allele consequence twice. So
> I'm getting phenotype info of A,T written in allele A consequences
> and in allele T consequences.
>
> How can I get the phenotype informartion for each allele
> sperately? I think Ensembl can handle this since in VCF output
> consequences are separated not only by transcript but also by
> alternative allele.
>
> Thank you,
>
> Best regards,
> Guillermo.
>
>
>
> On 26/03/15 12:57, Will McLaren wrote:
>> You will probably see odd behaviour if you mix versions of the
>> script / API / caches / databases. Feel free to experiment,
>> though we can't support such setups obviously.
>>
>> It works fine for me on 75 or 79 (i.e. using "git checkout
>> --release 75" in ensembl-tools, ensembl-variation, ensembl-core)
>>
>> Will
>>
>> On 26 March 2015 at 11:26, Guillermo Marco Puche
>> <guillermo.marco at sistemasgenomicos.com
>> <mailto:guillermo.marco at sistemasgenomicos.com>> wrote:
>>
>> I guess it's a problem with my API installation then.
>>
>> If I install latest API(79) and continue to use
>> variant_effect_predictor.pl
>> <http://variant_effect_predictor.pl> from version 75 will it
>> continue working or I'll get conflicts/weird behaviours?
>>
>> Thanks!
>>
>> Regards,
>> Guillermo.
>>
>>
>>
>> On 26/03/15 11:53, Will McLaren wrote:
>>> Example output (I set $Data::Dumper::Maxdepth = 1;):
>>>
>>> > echo "rs699" | perl -I ~/Git/guillermo/vep/
>>> variant_effect_predictor.pl
>>> <http://variant_effect_predictor.pl> -plugin Clinvar -data
>>> -force -db 75
>>> 2015-03-26 10:51:38 - Reading input from STDIN (or maybe you
>>> forgot to specify an input file?)...
>>> 2015-03-26 10:51:38 - Starting...
>>> 2015-03-26 10:51:38 - Detected format of input file as id
>>> 2015-03-26 10:51:38 - Read 1 variants into buffer
>>> 2015-03-26 10:51:38 - Checking for existing variations
>>> [===================================================================================================================================================================================================]
>>> [ 100% ]
>>> 2015-03-26 10:51:38 - Reading transcript data from cache
>>> and/or database
>>> [===================================================================================================================================================================================================]
>>> [ 100% ]
>>> 2015-03-26 10:51:38 - Retrieved 4 transcripts (0 mem, 0
>>> cached, 4 DB, 0 duplicates)
>>> 2015-03-26 10:51:38 - Analyzing chromosome 1
>>> 2015-03-26 10:51:38 - Analyzing variants
>>> [===================================================================================================================================================================================================]
>>> [ 100% ]
>>> 2015-03-26 10:51:38 - Calculating consequences
>>> $VAR1 = bless( {
>>> 'adaptor' =>
>>> 'Bio::EnsEMBL::Variation::DBSQL::PhenotypeAdaptor=HASH(0x43c39a8)',
>>> 'dbID' => '2853',
>>> 'name' => undef,
>>> 'description' => 'HYPERTENSION, ESSENTIAL, SUSCEPTIBILITY TO'
>>> }, 'Bio::EnsEMBL::Variation::Phenotype' );
>>> $VAR1 = bless( {
>>> 'adaptor' =>
>>> 'Bio::EnsEMBL::Variation::DBSQL::PhenotypeAdaptor=HASH(0x43c39a8)',
>>> 'dbID' => '20384',
>>> 'name' => undef,
>>> 'description' =>
>>> 'Susceptibility_to_progression_to_renal_failure_in_IgA_nephropathy'
>>> }, 'Bio::EnsEMBL::Variation::Phenotype' );
>>> $VAR1 = bless( {
>>> 'adaptor' =>
>>> 'Bio::EnsEMBL::Variation::DBSQL::PhenotypeAdaptor=HASH(0x43c39a8)',
>>> 'dbID' => '20369',
>>> 'name' => undef,
>>> 'description' => 'Preeclampsia,_susceptibility_to'
>>> }, 'Bio::EnsEMBL::Variation::Phenotype' );
>>> $VAR1 = bless( {
>>> 'adaptor' =>
>>> 'Bio::EnsEMBL::Variation::DBSQL::PhenotypeAdaptor=HASH(0x43c39a8)',
>>> 'dbID' => '26451',
>>> 'name' => undef,
>>> 'description' => 'HYPERTENSION,_ESSENTIAL,_SUSCEPTIBILITY_TO'
>>> }, 'Bio::EnsEMBL::Variation::Phenotype' );
>>> $VAR1 = bless( {
>>> 'adaptor' =>
>>> 'Bio::EnsEMBL::Variation::DBSQL::PhenotypeAdaptor=HASH(0x43c39a8)',
>>> 'dbID' => '1',
>>> 'name' => 'HGMD_MUTATION',
>>> 'description' => 'Annotated by HGMD but no phenotype
>>> description is publicly available'
>>> }, 'Bio::EnsEMBL::Variation::Phenotype' );
>>> $VAR1 = bless( {
>>> 'adaptor' =>
>>> 'Bio::EnsEMBL::Variation::DBSQL::PhenotypeAdaptor=HASH(0x43c39a8)',
>>> 'dbID' => '6522',
>>> 'name' => undef,
>>> 'description' => 'COSMIC:tumour_site:large_intestine'
>>> }, 'Bio::EnsEMBL::Variation::Phenotype' );
>>> $VAR1 = bless( {
>>> 'adaptor' =>
>>> 'Bio::EnsEMBL::Variation::DBSQL::PhenotypeAdaptor=HASH(0x43c39a8)',
>>> 'dbID' => '6529',
>>> 'name' => undef,
>>> 'description' => 'COSMIC:tumour_site:breast'
>>> }, 'Bio::EnsEMBL::Variation::Phenotype' );
>>> $VAR1 = bless( {
>>> 'adaptor' =>
>>> 'Bio::EnsEMBL::Variation::DBSQL::PhenotypeAdaptor=HASH(0x43c39a8)',
>>> 'dbID' => '2853',
>>> 'name' => undef,
>>> 'description' => 'HYPERTENSION, ESSENTIAL, SUSCEPTIBILITY TO'
>>> }, 'Bio::EnsEMBL::Variation::Phenotype' );
>>> $VAR1 = bless( {
>>> 'adaptor' =>
>>> 'Bio::EnsEMBL::Variation::DBSQL::PhenotypeAdaptor=HASH(0x43c39a8)',
>>> 'dbID' => '20384',
>>> 'name' => undef,
>>> 'description' =>
>>> 'Susceptibility_to_progression_to_renal_failure_in_IgA_nephropathy'
>>> }, 'Bio::EnsEMBL::Variation::Phenotype' );
>>> $VAR1 = bless( {
>>> 'adaptor' =>
>>> 'Bio::EnsEMBL::Variation::DBSQL::PhenotypeAdaptor=HASH(0x43c39a8)',
>>> 'dbID' => '20369',
>>> 'name' => undef,
>>> 'description' => 'Preeclampsia,_susceptibility_to'
>>> }, 'Bio::EnsEMBL::Variation::Phenotype' );
>>> $VAR1 = bless( {
>>> 'adaptor' =>
>>> 'Bio::EnsEMBL::Variation::DBSQL::PhenotypeAdaptor=HASH(0x43c39a8)',
>>> 'dbID' => '26451',
>>> 'name' => undef,
>>> 'description' => 'HYPERTENSION,_ESSENTIAL,_SUSCEPTIBILITY_TO'
>>> }, 'Bio::EnsEMBL::Variation::Phenotype' );
>>> $VAR1 = bless( {
>>> 'adaptor' =>
>>> 'Bio::EnsEMBL::Variation::DBSQL::PhenotypeAdaptor=HASH(0x43c39a8)',
>>> 'dbID' => '1',
>>> 'name' => 'HGMD_MUTATION',
>>> 'description' => 'Annotated by HGMD but no phenotype
>>> description is publicly available'
>>> }, 'Bio::EnsEMBL::Variation::Phenotype' );
>>> $VAR1 = bless( {
>>> 'adaptor' =>
>>> 'Bio::EnsEMBL::Variation::DBSQL::PhenotypeAdaptor=HASH(0x43c39a8)',
>>> 'dbID' => '6522',
>>> 'name' => undef,
>>> 'description' => 'COSMIC:tumour_site:large_intestine'
>>> }, 'Bio::EnsEMBL::Variation::Phenotype' );
>>> $VAR1 = bless( {
>>> 'adaptor' =>
>>> 'Bio::EnsEMBL::Variation::DBSQL::PhenotypeAdaptor=HASH(0x43c39a8)',
>>> 'dbID' => '6529',
>>> 'name' => undef,
>>> 'description' => 'COSMIC:tumour_site:breast'
>>> }, 'Bio::EnsEMBL::Variation::Phenotype' );
>>> 2015-03-26 10:51:38 - Processed 1 total variants (1
>>> vars/sec, 1 vars/sec total)
>>> 2015-03-26 10:51:38 - Wrote stats summary to
>>> variant_effect_output.txt_summary.html
>>> 2015-03-26 10:51:38 - Finished!
>>>
>>> On 26 March 2015 at 10:43, Guillermo Marco Puche
>>> <guillermo.marco at sistemasgenomicos.com
>>> <mailto:guillermo.marco at sistemasgenomicos.com>> wrote:
>>>
>>> Hello Will,
>>>
>>> I already had enabled "check_existing" on my VEP config
>>> template, however I followed your advice and updated
>>> code to force in the new() method with your code.
>>> I'm still getting no prints of line 64:
>>>
>>> printDumper($pf->phenotype());
>>>
>>> Are you getting any output printed? As I said I get no
>>> errors but nothing is printed neither. This data dumper
>>> should be printing result of phenotype() method call.
>>>
>>> Regards,
>>> Guillermo.
>>>
>>>
>>>
>>> On 26/03/15 11:05, Will McLaren wrote:
>>>> I think perhaps you haven't enabled --check_existing;
>>>> this is required for $vf->{existing} to get populated.
>>>>
>>>> You can force it on in the new() method of your plugin:
>>>>
>>>> $self->{config}->{check_existing} = 1;
>>>>
>>>> It then works for me on release/75 and release/79.
>>>>
>>>> Will
>>>>
>>>> On 25 March 2015 at 17:35, Guillermo Marco Puche
>>>> <guillermo.marco at sistemasgenomicos.com
>>>> <mailto:guillermo.marco at sistemasgenomicos.com>> wrote:
>>>>
>>>> Hello Will,
>>>>
>>>> With your explanations I'm trying to call phenotype
>>>> (as you said I was accessing the hashref directly).
>>>> I'm using input set you linked. However my local
>>>> Ensembl installation is v75.
>>>>
>>>> This is the code of the plugin:
>>>> https://github.com/guillermomarco/vep/blob/master/Clinvar.pm
>>>>
>>>> I'm getting absolutelty no info nor errors. I've no
>>>> idea if this is an issue with my database/API
>>>> version or with the plugin code itself.
>>>>
>>>> Regards,
>>>> Guillermo.
>>>>
>>>>
>>>>
>>>> On 16/03/15 17:50, Will McLaren wrote:
>>>>> The "is_significant" field is an internal flag
>>>>> that doesn't necessarily have the meaning you
>>>>> expect; it is used to distinguish between genuine
>>>>> reported associations and e.g. non-significant
>>>>> associations reported from genome-wide studies.
>>>>>
>>>>> You should not see undef for phenotype; I suspect
>>>>> you are accessing the hashref directly
>>>>> ($pf->{phenotype}) rather than making the method
>>>>> call ($pf->phenotype()).
>>>>>
>>>>> You could try
>>>>> ftp://ftp.ensembl.org/pub/release-79/variation/vcf/homo_sapiens/Homo_sapiens_clinically_associated.vcf.gz
>>>>> as a test input set.
>>>>>
>>>>> Will
>>>>>
>>>>> On 16 March 2015 at 16:39, Guillermo Marco Puche
>>>>> <guillermo.marco at sistemasgenomicos.com
>>>>> <mailto:guillermo.marco at sistemasgenomicos.com>> wrote:
>>>>>
>>>>> Hi Will,
>>>>>
>>>>> Thank you for your quick response! Very
>>>>> clarifying.
>>>>>
>>>>> I guess that the way to retrieve ClinVar data
>>>>> I posted is correct. With my test dataset I've
>>>>> only seen "is_significant" values of "1" and
>>>>> undef 'phenotype' values. I think I need a
>>>>> synthetic vcf with ClinVar annotation variants
>>>>> to very that the plugin is working.
>>>>>
>>>>> I've been looking on Ensembl website for a
>>>>> test dataset. I think you don't provide any
>>>>> right? Correct me if I'm wrong.
>>>>>
>>>>> Thanks!
>>>>>
>>>>> Regards,
>>>>> Guillermo.
>>>>>
>>>>>
>>>>> On 16/03/15 16:16, Will McLaren wrote:
>>>>>> Hi Guillermo,
>>>>>>
>>>>>> To get the rest of that data in the table you
>>>>>> need to access the additional attributes of
>>>>>> the PhenotypeFeature object, something like:
>>>>>>
>>>>>> my $attr = $pfs->[0]->get_all_attributes;
>>>>>> print "$_:".$attr->{$_}."\t" for keys %$attr;
>>>>>> print "\n;
>>>>>>
>>>>>> Regards
>>>>>>
>>>>>> Will
>>>>>>
>>>>>> More info: the reason these data are stored
>>>>>> as attributes is due to the diverse data
>>>>>> sources and types that we import into our
>>>>>> phenotype schema; to create a database column
>>>>>> and corresponding API method for each data
>>>>>> type (p-value, review status, risk allele,
>>>>>> external ID etc etc) would be cumbersome and
>>>>>> inefficient. To this end we provide a few
>>>>>> methods that shortcut the attribute approach
>>>>>> for the most common data types; everything
>>>>>> else must be accessed through the attributes
>>>>>> method. This is a common theme across the
>>>>>> Ensembl API.
>>>>>>
>>>>>> On 13 March 2015 at 12:03, Guillermo Marco
>>>>>> Puche <guillermo.marco at sistemasgenomicos.com
>>>>>> <mailto:guillermo.marco at sistemasgenomicos.com>>
>>>>>> wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I'm trying to retrieve ClinVar
>>>>>> information with the code example you
>>>>>> provided.
>>>>>>
>>>>>> my $self = shift;
>>>>>> my $tva = shift;
>>>>>> my $vf = $tva->variation_feature;
>>>>>> my $pfa =
>>>>>> $self->{config}->{reg}->get_adaptor('human','variation','phenotypefeature');
>>>>>>
>>>>>> foreach my
>>>>>> $known_var(@{$vf->{existing} || []}) {
>>>>>> foreach my
>>>>>> $pf(@{$pfa->fetch_all_by_object_id($known_var->{variation_name})})
>>>>>> {
>>>>>> if ($pf->{'source'} eq
>>>>>> "dbSNP_ClinVar"){
>>>>>> print
>>>>>> "$pf->{'source'}\t$pf->{'external_id'}\t$pf->{'is_significant'}\t$pf->{'phenotype'}\n",
>>>>>> ;
>>>>>> }
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> As you can see I'm "filtering" the
>>>>>> results to only output phenotype feature
>>>>>> when source is dbSNP_ClinVar. I don't
>>>>>> know why but I guess filtering should be
>>>>>> done when doing the "fetch_all".
>>>>>>
>>>>>> On the other hand I'm trying to retrieve
>>>>>> Disease, Source and Clinical Significance
>>>>>> from this example table:
>>>>>> http://www.ensembl.org/Homo_sapiens/Variation/Phenotype?db=core;r=8:19955518-19956518;v=rs268;vdb=variation;vf=266
>>>>>>
>>>>>> I think I'm doing something wrong I got
>>>>>> totally lost in Phenotypefeature.
>>>>>>
>>>>>> Regards,
>>>>>> Guillermo.
>>>>>>
>>>>>>
>>>>>> On 02/03/15 16:05, Will McLaren wrote:
>>>>>>> If you enable the --check_existing flag
>>>>>>> when you run the VEP, you'll be able to
>>>>>>> see any known co-located variants
>>>>>>> attached to the VariationFeature object
>>>>>>> in your plugin:
>>>>>>>
>>>>>>> sub run {
>>>>>>> my $self = shift;
>>>>>>> my $tva = shift;
>>>>>>> my $vf = $tva->variation_feature;
>>>>>>>
>>>>>>> foreach my
>>>>>>> $known_var(@{$vf->{existing} || []}) {
>>>>>>> # do stuff
>>>>>>> }
>>>>>>> }
>>>>>>>
>>>>>>> The $known_var is not an API object but
>>>>>>> a simple hashref with a number of
>>>>>>> fields; you're probably interested in
>>>>>>> $known_var->{clin_sig}
>>>>>>>
>>>>>>> However, as I mentioned, this is the
>>>>>>> only data that is stored in the cache.
>>>>>>> To access the rating and the specific
>>>>>>> disease association, you'll need to make
>>>>>>> calls to the database by getting an
>>>>>>> adaptor, something like:
>>>>>>>
>>>>>>> sub run {
>>>>>>> my $self = shift;
>>>>>>> my $tva = shift;
>>>>>>> my $vf = $tva->variation_feature;
>>>>>>> my $pfa =
>>>>>>> $self->{config}->{reg}->get_adaptor('human','variation','phenotypefeature');
>>>>>>>
>>>>>>> foreach my
>>>>>>> $known_var(@{$vf->{existing} || []}) {
>>>>>>> foreach my
>>>>>>> $pf(@{$pfa->fetch_all_by_object_id($known_var->{variation_name})})
>>>>>>> {
>>>>>>> # do stuff
>>>>>>> }
>>>>>>> }
>>>>>>> }
>>>>>>>
>>>>>>> Be aware that this will access the
>>>>>>> database, so unless you have a local
>>>>>>> copy please don't run this sort of code
>>>>>>> on genome-wide VCFs using our public DB
>>>>>>> server.
>>>>>>>
>>>>>>> Regards
>>>>>>>
>>>>>>> Will
>>>>>>>
>>>>>>> On 2 March 2015 at 14:47, Guillermo
>>>>>>> Marco Puche
>>>>>>> <guillermo.marco at sistemasgenomicos.com
>>>>>>> <mailto:guillermo.marco at sistemasgenomicos.com>>
>>>>>>> wrote:
>>>>>>>
>>>>>>> Hi Will,
>>>>>>>
>>>>>>> Indeed I'm looking to retrieve this
>>>>>>> information from VEP plugin.
>>>>>>>
>>>>>>> Regards,
>>>>>>> Guillermo.
>>>>>>>
>>>>>>>
>>>>>>> On 02/03/15 15:25, Will McLaren wrote:
>>>>>>>> Hi Guillermo,
>>>>>>>>
>>>>>>>> The detailed ClinVar information is
>>>>>>>> stored against PhenotypeFeature
>>>>>>>> objects (each SNP/disease pairing
>>>>>>>> gets its own entry in ClinVar, e.g.
>>>>>>>> http://www.ncbi.nlm.nih.gov/clinvar/RCV000019691.2,
>>>>>>>> http://www.ncbi.nlm.nih.gov/clinvar/RCV000019692.2/,
>>>>>>>> http://www.ncbi.nlm.nih.gov/clinvar/RCV000019693.2/
>>>>>>>> for rs699).
>>>>>>>>
>>>>>>>> The rating (and indeed the clinical
>>>>>>>> significance) is stored as an
>>>>>>>> attribute on the PhenotypeFeature
>>>>>>>> object; you can retrieve this with
>>>>>>>> the get_all_attributes() method.
>>>>>>>>
>>>>>>>> See
>>>>>>>> http://www.ensembl.org/info/docs/Doxygen/variation-api/classBio_1_1EnsEMBL_1_1Variation_1_1PhenotypeFeature.html
>>>>>>>> and
>>>>>>>> http://www.ensembl.org/info/docs/api/variation/variation_tutorial.html#phenotype
>>>>>>>> for more info.
>>>>>>>>
>>>>>>>> Bio::EnsEMBL::Variation::Utils::VEP::get_clin_sig()
>>>>>>>> is an internal method that you
>>>>>>>> should not use.
>>>>>>>>
>>>>>>>> The VEP cache contains the list of
>>>>>>>> clinical significance states for
>>>>>>>> each variant, but neither the
>>>>>>>> disease association or the rating.
>>>>>>>> If you want help getting access to
>>>>>>>> this data via a plugin, let me know
>>>>>>>> as it's a little more involved than
>>>>>>>> the API methods above (though it is
>>>>>>>> faster as no database access is
>>>>>>>> required).
>>>>>>>>
>>>>>>>> Regards
>>>>>>>>
>>>>>>>> Will McLaren
>>>>>>>> Ensembl Variation
>>>>>>>>
>>>>>>>> On 2 March 2015 at 14:06, Guillermo
>>>>>>>> Marco Puche
>>>>>>>> <guillermo.marco at sistemasgenomicos.com
>>>>>>>> <mailto:guillermo.marco at sistemasgenomicos.com>>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> Dear devs,
>>>>>>>>
>>>>>>>> I'm looking forward to retrieve
>>>>>>>> ClinVar information and add it
>>>>>>>> to VEP annotation. From my
>>>>>>>> understanding I should be able
>>>>>>>> to retrieve "Clinical
>>>>>>>> significance" and "ClinVar Rating".
>>>>>>>>
>>>>>>>> I've been looking the Varation
>>>>>>>> API, and I'm confused. I guess
>>>>>>>> for significance I should use
>>>>>>>> Bio::EnsEMBL::Variation::Utils::VEP::get_clin_sig()
>>>>>>>> or
>>>>>>>> Bio::EnsEMBL::Variation::VariationFeature::get_all_clinical_significance_states().
>>>>>>>>
>>>>>>>> What about ClinVar rating? Is
>>>>>>>> it possible to retrieve it from
>>>>>>>> API?
>>>>>>>>
>>>>>>>> Thanks!
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>> Guillermo.
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Dev mailing list
>>>>>>>> Dev at ensembl.org
>>>>>>>> <mailto:Dev at ensembl.org>
>>>>>>>> Posting guidelines and
>>>>>>>> subscribe/unsubscribe info:
>>>>>>>> http://lists.ensembl.org/mailman/listinfo/dev
>>>>>>>> Ensembl Blog:
>>>>>>>> http://www.ensembl.info/
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Dev mailing list Dev at ensembl.org
>>>>> <mailto:Dev at ensembl.org>
>>>>> Posting guidelines and subscribe/unsubscribe
>>>>> info:
>>>>> http://lists.ensembl.org/mailman/listinfo/dev
>>>>> Ensembl Blog: http://www.ensembl.info/
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Dev mailing listDev at ensembl.org <mailto:Dev at ensembl.org>
>>>>> Posting guidelines and subscribe/unsubscribe info:http://lists.ensembl.org/mailman/listinfo/dev
>>>>> Ensembl Blog:http://www.ensembl.info/
>>>>
>>>> _______________________________________________
>>>> Dev mailing list Dev at ensembl.org
>>>> <mailto:Dev at ensembl.org>
>>>> Posting guidelines and subscribe/unsubscribe info:
>>>> http://lists.ensembl.org/mailman/listinfo/dev
>>>> Ensembl Blog: http://www.ensembl.info/
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Dev mailing listDev at ensembl.org <mailto:Dev at ensembl.org>
>>>> Posting guidelines and subscribe/unsubscribe info:http://lists.ensembl.org/mailman/listinfo/dev
>>>> Ensembl Blog:http://www.ensembl.info/
>>>
>>> _______________________________________________
>>> Dev mailing list Dev at ensembl.org <mailto:Dev at ensembl.org>
>>> Posting guidelines and subscribe/unsubscribe info:
>>> http://lists.ensembl.org/mailman/listinfo/dev
>>> Ensembl Blog: http://www.ensembl.info/
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Dev mailing listDev at ensembl.org <mailto:Dev at ensembl.org>
>>> Posting guidelines and subscribe/unsubscribe info:http://lists.ensembl.org/mailman/listinfo/dev
>>> Ensembl Blog:http://www.ensembl.info/
>>
>> _______________________________________________
>> Dev mailing list Dev at ensembl.org <mailto:Dev at ensembl.org>
>> Posting guidelines and subscribe/unsubscribe info:
>> http://lists.ensembl.org/mailman/listinfo/dev
>> Ensembl Blog: http://www.ensembl.info/
>>
>>
>>
>>
>> _______________________________________________
>> Dev mailing listDev at ensembl.org <mailto:Dev at ensembl.org>
>> Posting guidelines and subscribe/unsubscribe info:http://lists.ensembl.org/mailman/listinfo/dev
>> Ensembl Blog:http://www.ensembl.info/
>
>
> _______________________________________________
> Dev mailing list Dev at ensembl.org <mailto:Dev at ensembl.org>
> Posting guidelines and subscribe/unsubscribe info:
> http://lists.ensembl.org/mailman/listinfo/dev
> Ensembl Blog: http://www.ensembl.info/
>
>
>
>
> _______________________________________________
> Dev mailing listDev at ensembl.org
> Posting guidelines and subscribe/unsubscribe info:http://lists.ensembl.org/mailman/listinfo/dev
> Ensembl Blog:http://www.ensembl.info/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ensembl.org/pipermail/dev_ensembl.org/attachments/20150817/404cc42c/attachment.html>
More information about the Dev
mailing list