Validator Issues: Allow < > in NUMERIC datatype values (AGE and YEAR related)

[ritikakundra]

For deidentification purposes, the portal should not show age or year of birth (any PHI related attribute) pediatric and geriatric cases in the majority of studies. Therefore to capture the data, we modify the age to <18 and >89 (same with year). Validation fails this type of entry due to the datatype being Number. Can this be modified?

[pieterlukasse]

@ritikakundra this will need more testing in other views like study view and plots tab. How should these views deal with such data? For example:

Maybe @jjgao and @schultzn have an idea for this? I.e. how to plot such samples in this case?

[jjgao]

Good point. We could try to write some specially in frontend to handle that, but I don't think it's a high priority.

Maybe for the moment, we can allow them in the validator and ignore < or > in frontend (maybe in API?), so 89 instead of '>89' will be used?

[jjgao]

@zhx828 @ersinciftci what do you think?

[ersinciftci]

@jjgao what column of what table are we talking about?

[jjgao]

@ersinciftci attr_value in clinical_sample and clinical_patient

[ersinciftci]

@jjgao So some subset of the samples in a particular study have for example AGE values like <18, but other samples in the same study have normal number AGEs like 35?

[yichaoS]

public studies with this validation error "Value of numeric attribute is not a real number"

• brca_tcga_pub2015:
  column: HER2_COPY_NUMBER, CENT17_COPY_NUMBER values: >6, not amplified, polisomy, (2 more))
• egc_msk_2017: column: TOTAL_TIME_PERIOD_MONTHS, NUMBER OF_LINES_OF_TREATMENT_FOR_MET_DISEASE, ECOG_AT_STAGE_4_DX, (1 more) values: UNK, unk
• prad_fhcrc: column: PSA value: <0.03

[pieterlukasse]

@yichaoS for the UNK, unk values you can replace these by NA.

[jjgao]

@ersinciftci yes.

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[rmadupuri]

Closing this issue since both the validator and front-end now supports < >.