Backing patient & gene curation flags

[fschiettecatte]

We need to add two flags:

One to indicate whether the patient record in the response is indeed a patient (with backing data) as opposed to just data.

Another to indicate whether the genes in the response were manually curated or computationally curated.

As discussed in the Oct 24th 2017 meeting minutes.

[Relequestual]

...indicate whether the genes in the response were manually curated or computationally curated.

... by the database. I mean, DECIPHER, and assuming others, only know what the user has entered. We have no way to know how they came about that data. We assume everything is manualy curated in DECIPHER, but we do not know.

Is "probably" acceptable for the use case?

What are the uses cases for these?
I asusme they came out of the call meeting dated Oct 24th 2017 (which I couldn't make). Were there any minutes taken? (sorry if I've missed them).
I see it mentioned in the minutes. Is the use case just "end users might want to know"?

[jxchong]

@Relequestual This isn't so applicable to DECIPHER because I am pretty sure all of your genes were manually curated. It's more applicable to instances where a user ran some "automated analysis" and is submitting every single gene that came out of the program without manually curating the genes to remove candidates that are likely artifacts, biologically-implausible genes, etc. This would also apply to results from v2.0 where your "match" was a result of matching against the automated results of the node (e.g. PhenomeCentral) running Exomiser on a vcf, but again no human has reviewed the results.

As an end user, I'd definitely downweight matches that are for a candidate gene that was never reviewed by a human.

[Relequestual]

@jxchong This may be the intended use of DECIPHER, however we have had instanced where people have uploaded 40-100 varients for a single patient.

In addition, as our API uptake increases, it allows people to upload bulk records programtically, which might be included in a pipeline (although this is not our intended use). We can control which applications have API access, but it could be we should start tracking this information.

I'll make a not to bring it up at one of our meetings.