Stream: terminology
Topic: Finding vs Observable in Observation.code
Jay Lyle (Apr 06 2020 at 20:41):
The Gravity project proposes using Observations to capture present/absent questions about social determinants of health. I think this is correct. They also propose using Finding in Observation.code. Semantically I'd prefer Observable entity, so that when you combine it with a value you get a finding, and it doesn't conflict with the implicit Presence already baked into Finding. But the OE axis is immature both in content richness and in specificity, so I think I'm ok with Finding. Does this make sense?
Rob Hausam (Apr 06 2020 at 22:00):
What I want to avoid is using Observation.value as a de facto "negation indicator" for finding concepts in Observation.code by setting Observation.value to "absent" (since SNOMED CT finding concepts include the default context of "Present").
Rob Hausam (Apr 06 2020 at 23:01):
If we consider the meaning of Observation.value to be a "quantifier" generally of the meaning that is being represented by the Observation.code, where that quantification can be numerical (as in the common laboratory result case) or the extension of that to the logical endpoints of "presence" or "absence", then I think that I'm not quite as concerned about avoiding this. And if we have a consistent understanding that the "default" context of the concept is expected (or at least allowed) to be overridden or superseded by the explicit context supplied by the information model (in this case in Observation.value) or in a compositional expression (potentially using SNOMED CT or another terminology), then I'm also not as concerned about the use of "finding" concepts in Observation.code.
Jay Lyle (Apr 06 2020 at 23:41):
I think that makes sense. The fact that the Situation model complicates things is unfortunate, but it's there because there is a need.
So, #1, we agree that these symptom presence/absence questions should be Observations, not Conditions.
And #2, within Observation, we need a way to represent the presences and absences: an OE + presence/absence is best, but a Finding + presence/absence is feasible. And for those who may prefer a precoordinated value in code, they just don't exist. If we had the time & consensus, we'd create OEs for that, but we don't.
[tangent: lab values seem to be quantifiers; clinical loinc seems to be qualifiers; the .value property has manifest semantic flexibility. We may want to assert model bindings to make these values unambiguous, but until then, the pattern supports this amount of variety.]
Last updated: Apr 12 2022 at 19:14 UTC
