Allow Ascertain Pedigrees to create "pedigree cohorts" with NO "affecteds", and rework the UI text

[Viqsi]

So there was a significant conversation about the Ascertain Pedigrees module; the big turning point for it lead to (and is documented in) #260. That issue, though, is about the Second Public Release; this is what we're doing for the initial release.

After some discussion as to timetables and feasibility, Veronica came up with this sketch of what we could do immediately, which seemed workable:

Text for manual and/or top of page:

Ascertaining Pedigrees is a two-step procedure: First, you assemble a set of index cases, or an "index cohort." This could be, e.g., the set of all individuals with BP1 or BP2; the set of all individuals with a 'yes' response to a custom variable you have created; etc.. If you have not already done so, you can define your index cohort using "Build a Cohort." Second, you define ascertainment criteria for including Pedigrees in your selected "ascertained cohort." For example, you might simply request all relatives of everyone in your index cohort, or, you might require at least 2 relatives meeting certain criteria. For example, you might require at least 2 additional individuals in each pedigree with BP1 or BP2; or, you might require at least 4 additional individuals/pedigree with any affective diagnosis; etc. Note that for criteria involving multiple variables you will need to first use Define a Custom Variable to create a variable to use in this step. Additionally, you have the option of specifying a minimum pedigree size.

Design of interface:

Change "Parent Cohort" to "Index Cohort." Include text saying that if you haven't already defined your set of index cases go to Build Cohort to do so and then return to this step.

Add "Include all relatives of anyone in my index cohort" as an option before "Select Variables." And if that is checked make it clear that the user can skep right to the end (there are multiple ways to accomplish this, not sure which is the simplest). This is the one option I’d be willing to omit for now, but since you indicated it would be do-able I’m leaving it on my wish list.

Then add a heading: "Define ascertainment criteria"

Then select variables etc -- exactly what you already have in terms of functionality, just with some text editing:

(1) Instead of "Define Filter Criteria for Selected Variable," let's say "Select and constrain variable for pedigree ascertainment step."

(2) Instead of "match filter against this many pedigree members", let's say, "Apply ascertainment criteria"

I think this would do it.

I expect to revise that text for the top of the page (it's a bit long) and also significantly revise the docs on Ascertain Pedigrees to match. But this absolutely should be doable in the time we have, and it gets us much closer to something ideal.

[Viqsi]

For the record, I believe the backend will already let us do this. It might not be the cleanest of API calls, but it's certainly there. That's something I want to look into to be sure tho. Most of the work is in the UI.

[Viqsi]

This also potentially affects how we show pedigree previews, since they presume the presence of affecteds both in the title and in the "logic description". That may necessitate a little bit of braining.

[Viqsi]

Some changes are going to have to be made in the proc code, but I think it's still rapidly doable. The basic thing is that we're going to have to allow creation of pedigree cohorts with no constraining variable. That's also the flag we're going to use to identify when there's no point in displaying affecteds (because, with the monkeywrenching I'm looking at, it'd be identical to Total Individuals).

It's a little weirdish but it's doable.

[Viqsi]

The emergence of #265 has made it rather difficult for me to verify correctness of any work I try with the proc code changes mentioned above, but I suspect the proper approach is going to be "assume family_size Will Be Correct and proceed anyways". But I'm going to sleep on that first before I decide it's the way to go.

[Viqsi]

Veronica's feedback has been largely positive (and touched mostly on things other than this redesign - see #269), so I'm calling this one done.