Additional fields? Or how best to capture diverse European data

Development
, ,
10

To close this off:

  • measure_estimated: maps to the new valTreat header in measures, and will be treated in wide names like the attributes qualityFlag. value, and purpose. The wide-name formula for a measure or measure-value is compartment_specimen_fraction_measure_unit_aggregation_index_attribute where the attribute at the end is always either value, purpose, qualityFlag, or (now) valTreat.
  • measure_value_alpha: mapping value and value_alpha to the same field.
  • measure_value_normalization_method: Using the new “pre-populated and multiple attribute” wide name structure, creates the wide name: cl_2_AND_calcType__standardization__standard.
  • measures_name: maps to measure in the measures table.
  • site_code : resolved to map site_code to a parent siteID, but to not create a new sites table entry for the parent (@Sorin - let me know if you hate this idea).
  • Variant_code: maps to measure in the measures table (or “measure_name” in the current EUxODM structure)
  • Variant_name: This maps to group in the measures table.
  • ECDC_category: see this topic for the continuation of this discussion: New Table Proposal: Public Health Actions Table
  • WHO_category: see “ECDC_category” above.
  • Is_subvariant_of: To be continued in a separate discussion, if needed, but currently the suggestion is to drop this field and not record it in ODM.
  • Sample_size: a unit of “total # of samples”, ie. wat_sa_NR_hfMe_unitless_me_NA_sampleNum_value)
  • Variant_cases: a unit of “# of positive samples”, ie. wat_sa_NR_hfMe_unitless_me_NA_posSmple_value.

This covers all points raised, I’ll leave the topic open a little longer in case folks have other comments or additions. To @Sorin 's point about parent-child relationships for measures, I agree that it makes sense and could work elegantly. But because we already have measure sets, the additional relationship options would create some confusion. For something like sub variants too, it’s really not like most measures because it doesn’t change. So it’s a piece of metadata about a part (a measurement), and should (if logic is to be consistent) be stored in the parts table. Short of that, it makes more sense to point out for it, so maybe the lineage being stored in the sequencing info linked in the accessions table might be enough?