clingen-data-model / allele-registry-use-cases

Description and support material for a global allele registry
2 stars 0 forks source link

Review of UC101 #3

Open ppawliczek opened 9 years ago

ppawliczek commented 9 years ago

Who should have the right to register new alleles? We assumed that everybody can query Allele Registry about alleles. However in my mind not everybody should be allowed to register new alleles. This question is closely related to another issue: How the Allele Registry should be populated? I see two possible approaches here:

  1. Everyone is able to register new alleles - Allele Registry is empty at the beginning and it is populated by the users.
  2. Only some authenticated users can register new alleles - at the beginning we import some large set of common alleles to Allele Registry to make it usable, then some users with proper access rights can extend its knowledge by registering new alleles. What do you think?
larrybabb commented 9 years ago

Policy questions like these can be challenging to nail down. From a design perspective, however, I believe a user account with an authentication level (i.e. role) of submitter should exist. These submitters can submit. We can allow the policy-makers to decide who can be granted this authority.

Additionally, the bulk initialization and coordinating synchronization of sources of allele data like ClinVar into the Allele Registry should be determined by a policy-making group as well. We have clearly chosen to use ClinVar as a primary source of data for the Allele Registry. So, I would imagine we would set up an account with submission authority that is used by the initialization and regularly established synchronization processes that will keep the Allele Registry data in-sync with ClinVar. It may make sense to have dedicate a separate user account for each external database that follows this model (not sure). One feature that was discussed (not phase 1) was the idea that any new allele's and assertions that are created in the Allele Registry are submitted back to ClinVar, thus keeping the two relatively in-sync over time.

bpow commented 9 years ago

Thanks for starting the online discussion. I think it will be useful to get thoughts on this into written form.

I don't think we are necessarily as far apart on this as it may have sounded like on the last call. I definitely see the importance of having only registered users adding new alleles (so that we can address/mitigate the risk of DoS-- either intentional or accidental-- through techniques like throttling or direct interaction with the registered users involved.

Using "admin" as the role name concerns me a bit though, in that I think overly restricting who can request a new allele ID (or making the process too onerous) will severely limit the utility of this resource. There are not an effectively finite number of alleles that someone might need to refer to, and "rare variation is common", so it is the rule rather than the exception that we identify apparently-novel variants with each exome (even more so with genomes). I would foresee someone wanting to assign allele IDs for each of these. If this has to happen through a centralized resource with actual human admins reviewing this, then this will i) make it a much more time consuming process to get a new allele identifier and ii) will require substantial human effort on the part of the admins. Who would provide the resources to maintain this effort?

I think it makes a lot of sense to prepopulate with alleles from existing observations (ClinVar, ExAC, etc.) for the sake of efficiency. But I also think it will be important to make it as simple as possible for a researcher or clinical lab to register an apparently-novel allele as well.

srynobio commented 9 years ago

One question I have for this step. Should we add the step of Canonicalization of this novel SimpleAllele, for clarity.

cbizon commented 9 years ago

I have updated UC101 in response to the discussion on last week's allele registry call.