Measurement Table - are value_as_concept_id and value_as_number mutually exclusive?

[Alexdavv (Alexander Davydov)]

@noahengel

I agree with this sentiment; there are many contingencies for whether we would want one or both values. One caveat, however, is that a measurement_concept_id may only really lend itself to one particular result. Going off of your example:

Agree, most of the lab tests in LOINC and some in SNOMED have pre-defined scale types.

Here are the examples:

• Quantitative scale in LOINC and SNOMED:
  HIV 1 Ab [Units/volume] in Serum
  Syphilis test, quantitative

• Ordinal/Qualitative scale in LOINC and SNOMED:
  HIV 1 Ab [Presence] in Serum
  Syphilis test, qualitative

• Nominal scale in LOINC and SNOMED:
  Bacteria identified in Blood by Culture
  Weight change intent

We normally don’t want to store the result against the rules, right? So quantitative scale consist with value_as_number, while ordinal, qualitative and nominal scales - with value_as_concept_id.

Another story is ‘Quantitative or Ordinal scale’ in LOINC (antimicrobial testing concepts only) and a batch of mixed SNOMED concepts where the scale type is not even defined. A test result can be legitimately stored as either a number or a concept or even both at once. Why is it a problem? You can look into figures or concepts during analysis.

This discussion shows very well why the original numerical result should be always preserved. The issue is that some of the systems record both numerical result and its interpretation according to some criteria/standard that isn’t even specified. When it’s just above/below/between the normal range and once you have range high/low captured, it might be omitted since you can repeat the logic during the analysis. But when it comes to other categorical responses (no matter ordered or not, e.g. 1+, 2+, 3+, positive, reactive, intermediate), you might want to store it as value_as_concept_id. The major reason is simplification of the studies - no need to care about the normal ranges then. So the question is: do we allow to add value_as_concept_id to the value_as_number when measurement_concept_id is of quantitative scale? I’d say “yes” and the reason is that we’ll never clean it up. People do not follow the scales. What we’ve seen many times in the source within one single test is a mixture of numerical/categorical values and a lot of different descriptors in the same field (quality of the sample, level of alert, etc.).

A possible improvement would be an introduction of the interpretation_concept_id filed which implies an additional interpretation (that not expected directly within this test) of the numerical result. But this would be a great amount of work on the ETL side to sort this out.

@noahengel

HIV status, however, may be logged with the concept ID ‘Finding of HIV status’ (4276586).

This concept implies the antibody test and hasn’t scale type specified though. But from the context, it should not be numerical.

@noahengel

1. If a source value provides us with two pieces of information (e.g. ‘zzz | Positive’), should we accept both pieces of information (e.g. value_as_number = ‘zzz’ and value_as_concept_id = ‘Positive’) in one record or should the information be triaged into two separate records , if possible?

I’d not suggest splitting the records. 1 record = 1 test. Even though you have one number + several interpretations, keep the number and try to map to one single concept. ‘Abnormal presence of’ is a good example.

@noahengel

2. Are there any measurement_concept_ids that may unequivocally lend itself to having both a value_as_concept_id and a value_as_number ? My understanding is that every record should only represent one particular finding and that the measurement_concept_id defines whether or not a result is inherently numeric in nature (e.g. viral load) or categorical (HIV status).

Please see above.

@aostropolets

I thought that it’s not required to infer if values are below/above the normal range during the ETL

100% agree. Let’s at least sort out what is provided by the source.