Remove the need to input BMI

[AmandaBirmingham]

[Note that I can't scope this one without knowing if we would allow users to input BMI if they already had it calculated.]

This suggestion is from Alan Jarmusch in the Dorrestein lab, via email:

a few things that I think the end user will appreciate: .... ii) remove the need to input BMI as that can be calculated from height and weight (unless this is used as an accuracy measure)

[AmandaBirmingham]

This would be a rather fraught requirement, because in some cases, users will in fact have BMI in their metadata and will want to enter it. Do we tell them they are not allowed to? Alternately, if we DO let them enter it, what do we do if it DOESN'T match the BMI we calculate internally via height and weight?

If we just accept their provided-but-not-matching BMI and dump it into the database, then we risk later having meta-analyses pull out the data from this experiment as being interestingly distinct from other experiments--"gee, all the people in experiment X have better outcomes at their BMI than people in other experiments do at that BMI! Clearly the treatment from experiment X must be very effective!", when in fact the BMIs just aren't comparable between experiment X and others.

On balance, I think the risk of introducing data that is really incompatible but that looks compatible is too great, and thus I'm not in favor of this suggestion.

[adswafford]

How about allowing BMI but removing it from the required fields since we do require height and weight, especially for pediatric subjects where BMI isn't relevant. Later if we want to do math to get our own BMI, we can call this 'calculated_BMI' so it won't conflict with any entered BMIs?

@ackermag what do you think?

[ackermag]

Keep in mind that EBI has asked that we rename the field 'host_body_mass_index'. I suggest calculating (math) BMI where height and weight is given where life_stage = 'adult' and host_common_name = 'human'

On Thu, Mar 8, 2018 at 9:19 PM, adswafford notifications@github.com wrote:

How about allowing BMI but removing it from the required fields since we do require height and weight, especially for pediatric subjects where BMI isn't relevant. Later if we want to do math to get our own BMI, we can call this 'calculated_BMI' so it won't conflict with any entered BMIs?

@ackermag https://github.com/ackermag what do you think?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ucsd-ccbb/cmi_metadata_wizard/issues/122#issuecomment-371716406, or mute the thread https://github.com/notifications/unsubscribe-auth/AB69gP_Ni7YczVb_VlSfZ9a9q3W344bXks5tchDxgaJpZM4Sg8Pm .

-- Gail Ackermann Knight Lab UCSD glackermann@ucsd.edu ackermag@ucsd.edu

[adswafford]

@ackermag , a challenge with this is that the wizard doesn't make a distinction between adults and children in the selection, so I think this is the easiest implementation is to make this with human-adult and human-juvenile packages.

Human adult we enforce and calculate the column 'host_body_mass_index' for adult packages: =IFERROR([weight]/ [height]^2,IF(OR([weight]='not provided',[[height]='not provided'),'not provided','not collected']

Sound good?

[ackermag]

makes sense to me

On Fri, Apr 6, 2018 at 10:25 AM, adswafford notifications@github.com wrote:

@ackermag https://github.com/ackermag , a challenge with this is that the wizard doesn't make a distinction between adults and children in the selection, so I think this is the easiest implementation is to make this with human-adult and human-juvenile packages.

Human adult we enforce and calculate the column 'host_body_mass_index' for adult packages: =IFERROR([weight]/ [height]^2,IF(OR([weight]='not provided',[[height]='not provided'),'not provided','not collected']

Sound good?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ucsd-ccbb/cmi_metadata_wizard/issues/122#issuecomment-379321101, or mute the thread https://github.com/notifications/unsubscribe-auth/AB69gHWNQgzHo4S4pVNdDi762-pCv5E3ks5tl6UbgaJpZM4Sg8Pm .

-- Gail Ackermann Knight Lab UCSD glackermann@ucsd.edu ackermag@ucsd.edu

[AmandaBirmingham]

I am going to push back strongly on the above suggestion https://github.com/ucsd-ccbb/cmi_metadata_wizard/issues/122#issuecomment-379321101 . The ability to calculate a column value in the metadata spreadsheet using a one-off formula (i.e., not one generated from the schema definition) based on arbitrary other columns in that sheet does not exist in the metadata wizard. Adding it would be a major expansion of functionality and a quantum leap in complexity. However, doing so would be a poor allocation of effort because Excel is not a good tool for this sort of arbitrary conditional logic--it should be handled in software code instead.

We have discussed all along that the Excel metadata wizard spreadsheet is the first stage of metadata validation, and that it will need to be uploaded to a software tool that will do additional more complex validation and modification that Excel can't handle (for example, checking that ontology terms entered are sensible, merging spreadsheets from different sample types, etc). This software- (rather than Excel-)based second stage is the logical place to add any calculated columns.

I understand that the second stage will not be included in the beta (and may be tabled until Qiita is extended to read in the metadata spreadsheets, when it is written as part of that import process). However, if removing the BMI (i.e. host_body_mass_index) from the list of required fields from the user is truly a must-have for the beta launch, it should be implemented in a code-based second stage.

My opinion is that removing the need for the user to input BMI is not a high enough priority to undertake this effort and that this enhancement should be tabled until later.

[adswafford]

Thanks for the detailed feedback and I think your concerns and thoughts on this make sense perfect sense to me.

Let's change this to a someday maybe so the issue will be on our radar until we decide what to do with it.

With the new positive shift in maintenance and development plans, I think it would be good to get together next week to figure out what should go where and when so that we have a short, mid and long term strategy for the vrious components.

Thanks again for detailing the concerns and for the push back on this given the challenges it creates and the lack of fit between this issue and Excel as the tool to rectify it.

On Fri, Apr 13, 2018, 1:23 PM Amanda Birmingham notifications@github.com wrote:

Assigned #122 https://github.com/ucsd-ccbb/cmi_metadata_wizard/issues/122 to @adswafford https://github.com/adswafford.

— You are receiving this because you were assigned. Reply to this email directly, view it on GitHub https://github.com/ucsd-ccbb/cmi_metadata_wizard/issues/122#event-1574079698, or mute the thread https://github.com/notifications/unsubscribe-auth/AZxBhq-ZTr8THZG7p4pFhubfKtKtfzYfks5toQlFgaJpZM4Sg8Pm .