# Additional fields? Or how best to capture diverse European data

**URL:** <https://odm.discourse.group/t/additional-fields-or-how-best-to-capture-diverse-european-data/175>\
**Category:** Development\
**Tags:** odm-v2, wide-names, mapping\
**Created:** [January 3, 2025, 10:12pm UTC](https://odm.discourse.group/t/additional-fields-or-how-best-to-capture-diverse-european-data/175 "2025-01-03T22:12:48Z")\
**Posts on this page:** 1\
**Showing post:** 10

<div class="post-metadata">

**Author:** ![matthomson](https://avatars.discourse-cdn.com/v4/letter/m/dec6dc/32.png) [@matthomson](https://odm.discourse.group/u/matthomson)\
**Post date:** [February 20, 2025, 8:54pm UTC](https://odm.discourse.group/t/additional-fields-or-how-best-to-capture-diverse-european-data/175/10 "2025-02-20T20:54:50Z")

</div>

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](https://odm.discourse.group/t/new-table-proposal-public-health-actions-table/176)
- **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?

---

_[View the full topic](https://odm.discourse.group/t/additional-fields-or-how-best-to-capture-diverse-european-data/175)._