Modeling HIV Viral Load results

Hi all,

We are looking into our future data model for HIV Viral Load test results, and I wanted to check with the terminology and HIV domain experts here for what they would recommend. Here is my tentative proposal based on what I am finding today in OCL:

In addition to any general feedback which we would welcome, we have some specific questions on the above:

  • If a result is detected, we always want to capture the numeric result. So does it make sense to include “DETECTED” as a possible qualitative result answer?
  • For an HIV Viral Load, is “NOT DETECTED” a viable answer, or should BEYOND DETECTABLE LIMIT generally always be used, and we should not include “NOT DETECTED” as a possble qualitative result answer?
  • Does having a new Concept for “DETECTABLE LOWER LIMIT” make sense? Often I see our lab reporting answers like “<500” or “<300” or “<1000”. For most of our reporting, these are generally all going to be bucketed under “undetectable”, but it would seem valuable to capture the detectable limit if it is reported by the lab.

Thanks for any feedback! (cc @akanter)

This looks good, Mike. But definitely would value others’ expertise. It’s likely clearer to use ‘HIV viral load, quantitative’ for the numeric value, but that could be the fully specified name with a synonym of ‘HIV viral load’.

A reminder that we not to use UPPER CASE for concept names. Our standard convention is for ‘Sentence case’. Sentence case is the conventional way of using capital letters in a sentence - capitalizing only the first word and any proper nouns. IS THAT COOL?


@akanter Could you review this design? We’ll be implementing this shortly. Thanks.

Yikes, how did I miss this?

So the plan is to either populate the viral load (quantitative) or HIV viral load (qualitative)? If beyond detectable limit, then record the limit in a new concept?

This seems OK to me. The Test Name was meant to be a procedure concept and not a named test, but I guess there is no reason not to use the brand name as well.

I am presuming that the detectable lower limit does not require units as it would be used in conjunction with a particular test. Otherwise, I think you would not be able to use a numeric value. We could create a detectable lower limit UNITS which would be unambiguous (and then you’d just have to populate it automatically or leave blank and assume copies/mL.

Based on what we have done with UgandaEMR:

  1. Beyond Detectable limit and Not Detected seem to be the same

  2. Due to the fact that different machines are used in analysing the samples so it may be 20, 50, and probably 80 copies/ml this may create issues with interpreting DETECTABLE LOWER LIMIT

  3. Currently we always store 3 values for a viral load:

  • Viral Load Date (when the patient was bled)
  • Viral Load Qualitative
  • HIV Viral Load: the actual detected copies if detected, 1 if not detected, and nothing if poor sample quality is selected. This is because if there are issues with the sample, the last viral load value still remains in force
  1. The reason for storing a 1 for non detected viral loads was to do with Cohort builder, if you did not save a value, it always pulled the last VL value - which may be wrong, so u may need to run a test case for that also in reporting.

Steven, that last point was interesting and I hadn’t thought about it before. So if you are trying to combine numeric and non-numeric data in the cohort, and you don’t put something in the numeric field, you don’t get what you want since the last value was non-numeric. It would seem like 0 would be appropriate instead of 1 WITH the addition of the nondetectable lower limit. If the test was poor quality, we wouldn’t want to count that value anyway as a valid test.

@akanter a viral load of 0 has the connotation that the patient has been cured, hence the 1, since machine detection currently stops at 20 copies/ml.

I agree on the non valid test, the last value is the important one - but each viral load result needs a combination to be valid

To be honest, a result of 0 shouldn’t mean cured. It just means undetectable and potentially suppressed. But I don’t like it for invalid tests. If you still want to plot it seems that whatever you put in the numeric column is replaced by the lower limit if its flagged as undetectable…

@akanter while it may not for a clinician, we are tackling it from a perspective that the users of the data may be untrained expert clients. However using the lower limit is a good idea too

This is a common enough challenge, that perhaps we should poll the community about data best practices. I think there are several challenges here, including plotting/trending data with a <xxx copies/ml and intersecting numeric and non-numeric data. The cohort builder limitation is a unique requirement. @mseaton, do you have additional input?

It is a good question. We also have requirements that come up for viral load, where we want to know, for example, whether a particular result is < 1000 or not, and this needs to be able to both inspect the quantitative result and the qualitative result + detection limit boundary to be able to make an accurate calculation. For Cohort Builder and reporting in general, this would typically require that the person doing the analysis know this and build a composition-type query that accounts for it. Or these types of calculations would need to be codified in a definition that can be reproducibly accessed.