[Candidate] Allow null Sex for scanner candidates

[CamilleBeau]

Brief summary of changes

Currently, the default value for "Sex" when a scanner is created is NULL. This causes an error when the candidate profile is visited from the family tab (as described in issue #6990). This PR makes it so that a Sex value is not required when selecting a Candidate to accommodate these Scanner candidates.

Testing instructions (if applicable)

1. Make sure that you can visit the candidate profile of a candidate with entity type scanner
2. Follow the procedure in the description of [Candidate parameter] Sibling link does not work #6990 and make sure that you do not encounter the error.

Link(s) to related issue(s)

• Resolves [Candidate parameter] Sibling link does not work #6990

[driusan]

I don't think this is supposed to be the case. The options for Sex in the candidate table are "enum('Male','Female','Other')". Aren't scanners supposed to be 'Other'? (@cmadjar @nicolasbrossard ?)

[cmadjar]

Right. I believe Sex = Other is (or should be) used for Scanners.

[driusan]

So can we close this?

[nicolasbrossard]

@driusan @cmadjar I think Other is misleading in the sense that it suggests that the entity is human and has a sex but it's neither Male nor Female. If Other is strictly reserved for scanners, then why not label it something like N/A (scanner)?

[driusan]

My understanding is that the options map directly from the (required) DICOM PatientSex column where scanners are classified as "O"(ther).

[nicolasbrossard]

@driusan Right. Maybe change the label to 'Other (scanner)'? Just to emphasize that when you select 'Other' you are not going to get any humans.

[CamilleBeau]

Are we decided on changing the "other" label for sex to "Other (scanner)" for scanners and continuing to not allow null sex?

[driusan]

No, I don't think "Other (scanner)" makes sense. "Other" does not mean it's a scanner, it means it's not Male or Female. (which happens to include scanners.)

[CamilleBeau]

No, I don't think "Other (scanner)" makes sense. "Other" does not mean it's a scanner, it means it's not Male or Female. (which happens to include scanners.)

@driusan So is the action plan to leave it as other, and change the sex of Scanners to "Other" instead of null so that it can still be mapped from DICOM PatientSex column?

[driusan]

@CamilleBeau I don't understand the question. Isn't that already the behaviour that this PR is trying to change it from?

Sorry for the delay in responding.

[CamilleBeau]

@CamilleBeau I don't understand the question. Isn't that already the behaviour that this PR is trying to change it from?

@driusan No this PR is working off of scanners having "null" as sex. I'm just a bit unclear of where we want to go with this based on the conversation in this PR. Do we want scanners to have "null", "other", or a unique scanner sex?

[driusan]

I think "Other", but maybe it's worth holding off until an imaging meeting.

[CamilleBeau]

I think "Other", but maybe it's worth holding off until an imaging meeting.

Ok that sounds good! I'll check in with this soon then.

[CamilleBeau]

@driusan Has an imaging meeting happened yet to give more insight on this?

[driusan]

As far as I know there hasn't been one yet.

[cmadjar]

Will be discussed on Friday. @CamilleBeau let me know if you want to join regarding this bit.

[cmadjar]

Discussed at the imaging meeting of June 11th 2021. Instead of modifying the structure of the table to fix the bug in the candidate parameter module, the candidate parameter module should be updated to allow Other sex.

Note: Scanners have the following sex values which is what is reflected in LORIS to identify the scanner's candidate sex: M (male), F (female), O (other). https://dicom.innolitics.com/ciods/general-ecg/patient/00100040

Closing the PR as discussed during the meeting.