@akanter suggests building a generic array to store lab/test results… but in the past people used the OBS record with the concept itself to hold the result. This topic is to start a discussion with the design team of how to best model lab/test results.
2 Likes
Thanks for starting this topic, @arbaughj and @akanter. Looking forward with more discussions how to best model it.
I believe that @r_friedman had modeled the orders separately from the results, so that there were two different concepts. The results are captured in the concepts traditionally identified as the lab result. These would then need to be placed in a convenience set (array) with things like the date ordered, date resulted, etc. I would think we would also add fields for qualitative result (very low, low, normal, high, very high, abnormal) and then perhaps a normal range field for low, high, etc. Would appreciate folks input here.
Maybe I don’t understand the context of this question. Are we trying to model the obs table in the concept dictionary for some reason?
I think this is a ciel meta data question. Which concepts are necessary for populating the obs table properly to document lab results in an interoperable manner.
I don’t think we have much feedback here. We really do need to propose a structure to support lab results which can interface properly with LIS systems and provide the necessary meta data to support CDSS and quality reporting. My recommendations above did not receive any feedback. @burke, @jteich, @darius any thoughts?
All of the groups I have worked with in the past have done the simple thing, e.g. if you’re recording a hemoglobin you just record that as a single obs, like:
- obs.concept = hemoglobin
- obs.valueNumeric = result
- obs.obsDatetime = specimen collection date if known, else date recorded
- obs.order = order this is in response to (not used if this is entered from paper)
I had always assumed that @akanter suggested that a better model would be to suppose we use a standard concept set for all the (optional) surrounding data, e.g. specimen collection date, result date, specimen ID. E.g. something like this HIV Test Result construct from CIEL, but generic.
I would suggest that for (a) compatibility with the easy/common way of doing things, with (b) support for a more sophisticated model, we try to define a standard construct for lab results that includes all the supporting information as additional observations, but stores the actual test result as the value of the test. (Not like in the HIV test construct I linked to above.)
E.g. you’d have:
- Lab Test Construct
- (Test and result, e.g. hemoglobin in my example, not explicitly in the concept set)
- this is where we’d store the test result
- obsDatetime of this obs should be the best possible approximation of the relevant clinical date
- Date test ordered (162078)
- Specimen collection date (159951)
- Date test resulted (162079)
- HIV test result received date (160082) => actually replace with a non-HIV-specific concept
- Test context status (162084)
- Specimen number (162086)
This representation is also easier for simple analyses, because you can just query for an obs of “hemoglobin > 5” instead of having to query for an obs group with an obs with “test = hemoglobin” and “numeric test result > 5”.
Agree that the result probably should be the value of the test concept. What you do you think about recording the result flag (high/low, etc.) and the normal range (low) and normal range (high) etc.?
In another thread @burke suggested that we should be adding “interpretation” as a new column on the obs table:
At present Bahmni is already storing lab tests in an obs group with an additional boolean obs for normal/abnormal.
So, I guess the long-run idea is that you’d store the normal/abnormalness directly on the obs that’s the test+value, but I could see us adding it as an additional concept in the concept set under discussion, to support platform versions < 2.1 (or whenever this gets added).