Stream: Orders and Observation WG
Topic: obs-7 is a problem
Lloyd McKenzie (Oct 28 2021 at 19:12):
I'm running into a situation where obs-7 creates a problem. The situation is as follows:
- when capturing race, there can be multiple coded values - which means the information needs to be captured as components, because the values won't be translations of each other, they're separate values
- however, you can also capture your race as a string - and in that case there's only one, and it encompasses all of the encoded information
The natural way to do this is to have a Observation.valueString and multiple Observation.component.valueCodeableConcepts. However, we can't do that right now because of the invariant. I think the decision to add the invariant hadn't contemplated the notion of having a string summary as a value.
Thoughts?
Lloyd McKenzie (Oct 28 2021 at 19:12):
@Hans Buitendijk @Eric Haas @Rob Hausam
Lloyd McKenzie (Oct 28 2021 at 19:59):
Note - similar problem for ethnicity, where you might have a single high-level code in addition to a description, and then a whole bunch of detailed codes.
Rob Hausam (Oct 28 2021 at 21:39):
@Lloyd McKenzie Yes, I think the issues are similar with ethnicity (though the way you stated it seems a little different). I think the main question we would need to answer is whether we want to allow or expect that Observation.value (specifically valueString) could be used as a "composite summary" of the values for multiple additional copies of the same observation (i.e. with the same value for 'code', as per obs-7) that are present in Observation.component. I think we created the invariant because we didn't believe that would be a logical or legitimate thing to do. The "race composite summary" observation really isn't the same thing as one or more of the individual "race" observations that would be in the instances of Observation.component. So maybe the "race composite summary" observation should have a different observation code?
Lloyd McKenzie (Oct 28 2021 at 22:20):
Well, it's easy to keep the constraint if you force different codes. But the reality is that a system might easily use 32624-9 and have a value that's a string, a value that's a code, or a bunch of components each with their own code. Saying we must introduce a new LOINC code just so we can maintain the Observation invariant seems backwards to me...
Eric Haas (Oct 29 2021 at 03:45):
Agree with Rob's recollection but to restate it - We wanted all the values for a given code in one place and not split between value and component value. If you want a valueText stick it in Component.valueString. Not sure there is much can do since is normative anyway. What are you proposing exactly and is the juice worth the squeeze? You are the first to complain ever.
Lloyd McKenzie (Oct 29 2021 at 04:40):
At the moment, the only technical way to make it work is to have a component valueString (and for ethnicity a 'restricted' CodeableConcept that essentially acts as a boolean of "Hispanic or not?"). But, given that it's an overall assessment, it seems very inappropriate to need to do so in component. I don't understand the desire to not split? Why not? If you've got a value that's overarching, put it in Observation.value. If you've got multiple child values, put them in component. What problem were you trying to avoid?
Jeffy Mathew Jose (Oct 29 2021 at 11:33):
Are we expecting this to happen in same Observation resource?
If so, Can we use some other field to capture the summary/description (say interpretation)?
Lloyd McKenzie (Oct 29 2021 at 13:07):
It's not an interpretation. It's not saying your race is good/bad/improving/worse/etc. It's saying, in the patient's own terms, what their race is. Essentially the CodeableConcept.text, with the challenge that the codes we need to send are codings of different 'aspects' of the race and thus can't appear as translations and must therefore be sent as components.
Eric Haas (Oct 30 2021 at 00:09):
I don't understand the desire to not split? Why not? If you've got a value that's overarching, put it in Observation.value. If you've got multiple child values, put them in component. What problem were you trying to avoid?
IMO What you are suggesting is giving a code multiple personalities. (See how it flies on the vocab stream. :-)). I think Rob's initial reaction is correct... use two codes.
As an aside - I am assuming you are trying map a QR to a bunch of observations.... how do these observations ultimately turn into the patient extensions?
Lloyd McKenzie (Oct 30 2021 at 02:19):
The proposal is actually to move from using the patient extensions to Observations - there's a requirement to capture who reported the race, whether it was determined algorithmically (apparently that's a thing), whether the information is deemed to be 'protected', and apparently there can be more than one race or ethnicity in play at once. E.g. "This is what the grandmother said, this is what the software algorithm said".
@Rob Hausam would you support submitting a new code to LOINC for this? Do you think they'd respond affirmatively?
Also, what happens for Ethnicity, where there's only one code for the 'summary' level, but can be multiple codes at the 'detail' level - would we have distinct codes for detailed ethnicity?
Richard Townley-O'Neill (Nov 01 2021 at 06:03):
While waiting for the new LOINC code you use two observations:
- one Observation with all of the Observation.component.value[x]:CodeableConcept and no Observation.value, and
- one Observation with Observation.value[x]:string and Observation.derivedFrom that points to the first Observation.
:grimacing:
Eric Haas (Nov 01 2021 at 14:50):
What happens for Ethnicity, where there's only one code for the 'summary' level, but can be multiple codes at the 'detail' level - would we have distinct codes for detailed ethnicity?
how are code heirarchies represented in general?? single codeableconcept with with multiple codings or multiple components or observations with unique codes??
Lloyd McKenzie (Nov 01 2021 at 16:11):
Depends on the type of hierarchy. If you've got a subsumption relationship, you can have all of the codings present on one CodeableConcept. But that requires all of the codes to be reasonable translations of each other. In this case, the codes are "partOf" rather than "is a".
Eric Haas (Nov 01 2021 at 16:23):
so what is the general pattern for part of codes?
Lloyd McKenzie (Nov 01 2021 at 16:52):
The repetitions have to be handled as components. But it doesn't really make sense for the high-level concept/text to also be components.
Last updated: Apr 12 2022 at 19:14 UTC
