NWSS Major Lab Method - Comparable Field

[matthomson]

This is a topic that has been brought up at a few times in the last two working group meetings, but it centres around how best to map the “major_lab_method” field in NWSS to the ODM, and/or whether a similar field should be created.

Specifically, “major_lab_method” is an integer value field where measures that have the same number are said to be “comparable”, by virtue of their method and site. This field is reported by the reporting jurisdictions to USCDC, and really serves most to mark a point of discontinuity within a given site. Because the comparability captured by the “major_lab_method” field is assessed by multiple labs running the same samples for the same site, and seeing whether the measures returned are comparable. This is not a measure of comparability between sites, but specifically within a site.

Within my initial mapping for NWSS, I marked major_lab_method as being akin to protocolID, which I - to a certain degree - still stand behind. But users have mentioned that perhaps more important is the information captured here which is the point of discontinuity (or continuity) within a given site when protocols and/or lab contractors change.

Below is list of suggestions to possibly address this:

1. A new table for combining the inputs from the protocols and sites tables, that captures this information. In practice this table would link siteIDs, protocolIDs, and potentially measures to show where continuity or discontinuity might occur. Pros are that it is effective and organized, cons are that it adds a new table, and increases model complexity (perhaps to the detriment of new users).

2. A “comparable protocols field” in the measures table (list) - this is less organized than option 1, but perhaps more parsimonious. This would be a field where one could list protocolIDs that generate comparable outcomes for the same site. It is repetitive across the table, of course, but also in looking at the NWSS data, this kind of continuity/discontinuity point is a minority situation. List-type variables are not ideal, and a prone to error, but this could be an effective solution.

3. Manage discontinuity in a specific site by versioning the siteID - have a parentID for a site, and then siteIDs for the different protocol sets. A bit of an abuse of the parent-child structure, and creates a bit of complexity in hierachizing the data, but may also be simple enough and somewhat effective.

If you have a preference or feedback on any of these numbered points, please respond below. Or if you have another idea you’d like to add to this list for consideration, please also explain in the replies.

Thank you!

@jeandavidt @dmanuel @Sorin

[matthomson]

To update on this - we discussed this subject at length at our biweekly working group meeting this morning.

Ultimately, all three of these options seem to somewhat break the semantics or logic of the model. To include something about protocols at the site level seems inappropriate, and to include additional secondary information on sites and protocols at the measure level also seems inappropriate and (as mentioned) unnecessarily duplicative.

The best option that was put forward was a suggestion from @jeandavidt which was that we could leverage the protocolRelationships table to establish a relationship of comparability. With that we could leverage the existing tables to report this, and all that it would require would be adding a new relationshipID value (comparable) and making the protocolIDContainer field mandatory-if (ie. mandatory for all relationships other than comparable. However, this still somewhat misses the site-specific connection of this field, so we discussed how we could also add a site-related field, but then t that point we’re basically creating a new table (à la option 1 above) but shoehorning it into an existing table.

We also discussed how this field within NWSS is maybe not as strong or as useful of a field as we would like. Within NWSS, the field seems to be used somewhat inconsistently - the integers are not unique enough to guarantee proper interpretation of the value. What’s more, is that the combination of site, lab, and jurisdiction already somewhat give this information. I can see from a perspective of parsimony that public health officials may want a more easily understandable flags for comparability, similar to the qualityFlag vs reportable fields - where we have one field that tells a non-WW-expert user whether data can be pooled or not. However, the metrics for determining or defining what is “comparable” seem quite opaque, and within wastewater experts will continue to disagree on what is “truly” comparable or not for a very long time.

So, in summary, mapping this field protocolID really might be sufficient. At most we could consider a relationship for “comparable” and “not comparable” to show continuity/discontinuity, but that might also need to be fleshed out a little further.