Stream: implementers
Topic: FHIRPath Subsumes
Grahame Grieve (Mar 14 2018 at 02:14):
GF#13451 - do we need subsumes? I don't think this is needed here. @Bryn Rhodes @Lloyd McKenzie
Lloyd McKenzie (Mar 14 2018 at 06:08):
If the Observation.code says "Blood Pressure" and the Observation.component.code says "Blood Pressure -sitting", that's as big an issue as if they both say "Blood Pressure".
Grahame Grieve (Mar 14 2018 at 06:44):
but that doesn't follow that it's always a problem. It seems reasonable that a component could provide further information to me .
Lloyd McKenzie (Mar 14 2018 at 14:09):
A component can provide further different information. But it can't represent the same observation. It needs to represent a qualifier or sub-section of the Observation. If you wanted to convey the codes for both "Blood Pressure" and "Blood Pressure-sitting", you would send them as multiple codings on Observation.code
Bryn Rhodes (Mar 14 2018 at 14:34):
I agree, the description of this item sounds like code equivalence, not subsumption. We deliberately excluded subsumption support from CQL, I'd suggest the same for FHIRPath (can always be added with an external implementation, but defining the operation in the spec means addressing a lot of variability).
Bryn Rhodes (Mar 14 2018 at 14:35):
Wait, what? "multiple codings on Observation.code"?
Bryn Rhodes (Mar 14 2018 at 14:35):
Isn't that a violation of a CodeableConcept?
Lloyd McKenzie (Mar 14 2018 at 15:19):
Multiple codings is standard in CodeableConcept - it allows you to provide multiple translations (often from different code systems, but can be from the same code system, for example if there's a need to satisfy multiple value sets.)
Lloyd McKenzie (Mar 14 2018 at 15:20):
The use-case is for more than just equivalence.
Bryn Rhodes (Mar 14 2018 at 15:33):
Yeah, but "Blood Pressure" and "Blood Pressure - sitting" are different concepts, so shouldn't those be represented with different CodeableConcept instances, not with different coding elements in the same CodeableConcept instance?
Lloyd McKenzie (Mar 14 2018 at 15:36):
Both are proper codings of what happened - they're just representing the concept at different levels of granularity.
Lloyd McKenzie (Mar 14 2018 at 15:37):
A coding that said "Blood Pressure" and another that said "Blood O2" would be misusing CodeableConcept. But having multiple codings that represent different levels of detail about the same thing is totally fine and expected.
Bryn Rhodes (Mar 14 2018 at 15:39):
Yeah, that's completely different from my current understanding, and my interpretation reading the documentation.
Lloyd McKenzie (Mar 14 2018 at 15:46):
There's no such thing as "true" concept equivalence across code systems. Different codes are always going to have different granularities. So long as both codings are representations of the concept that's present, they're valid translations. The "concept" in question is "what is the event happened to the patient". "Blood Pressure", "Blood Pressure-sitting", "Blood Pressure-sitting, large cuff size, second measurement" are all codings of the "concept" of that single event. On the other hand, "blood o2" would be talking about a different event - and would require it's own CodeableConcept.
Lloyd McKenzie (Mar 14 2018 at 15:49):
Perhaps the issue is this: "The different codings may have slightly different granularity due to the differences in the definitions of the underlying codes." I think "slightly" is misleading. There's no boundary on the granularity difference. One coding might say "Penecillin" and another might say "Apo Amoxicillin 20mg tablets". @Rob Hausam Do you agree?
Rob Hausam (Mar 14 2018 at 18:14):
@Lloyd McKenzie Yes, I do agree - to a point. We have to do this to some extent, but can't do it without limits (and unfortunately for that, there usually isn't a straightforward way to set hard limits on this). I think I would not expect or recommend including codes for both "Blood Pressure" and "Blood Pressure-sitting" as translations (assuming that they're from the same code system) - unless maybe there's a specific regulatory requirement or something like that that drives it. And I don't think it's correct to have codes for both "Penicillin" and "Apo Amoxicillin 20mg tablets" in the same data type instance - they're not the same thing, not just different granularity levels. But in principle we do have to do this to a "reasonable" extent.
Lloyd McKenzie (Mar 14 2018 at 18:55):
I agree you wouldn't send multiple levels of granularity from the same code system unless you were trying to meet the needs of different receivers who needed defferent codes - but that won't be uncommon. I thought Amoxicillin was a penecillin. However, the example still stands if the codes are for "Amoxicillin" vs. "Apo Amoxicillin 20mg tablets". Both are different granularities of coding of the same medication and if you have a receivers who need both codings, it's fine to have them on the same element.
Bryn Rhodes (Mar 14 2018 at 19:01):
For me, that's the problem, because they are different concepts, why not just say that those should be represented with different codeableconcepts?
Lloyd McKenzie (Mar 14 2018 at 19:08):
The underlying concept is the same. You'll never have a code that fully describes the real-world concept. You just have varying approximations of it. So long as the different codes are approximating the same aspect of the same real-world concept, you're fine. If we don't allow this, there's no way we could have an ICD10 code and a SNOMED code and a local code for the same Condition because there's no chance that they'd always have exactly the same granularity.
Lloyd McKenzie (Mar 14 2018 at 19:09):
Multiple codings are not conceptual equivalents. They are all parallel encodings of the same real-world fact.
Bryn Rhodes (Mar 14 2018 at 19:15):
I'm totally onboard with codes from different systems, and I get that there's never a perfect alignment between code systems. To clarify, when I say "code equivalence", I mean only that the code and system are the same, version and display can be different. But when codes from different systems are present within the same CodeableConcept, I thought the whole point of a CodeableConcept was that it sets up an implication of cross-system equivalence (a translation), and that's why I think having codes from the same system in a single CodeableConcept is a problem, we're saying they're translations then. Or we're using CodeableConcept in two very different ways with no ability to detect when we mean one thing versus another.
Rob Hausam (Mar 14 2018 at 19:16):
I (somewhat reluctantly) agree that Lloyd is right on this. The discomfort is not being able to explicitly say how far we can go with this (and no farther). It might be best (or even required) that "Amoxicillin" and "Apo Amoxicillin 20mg tablets" be coded in separate data type instances, rather than as multiple Codings in the same CodeableConcept, depending on the intended use, but in other cases it may be appropriate to do exactly what Lloyd has described.
Bryn Rhodes (Mar 14 2018 at 19:18):
But then how do we distinguish the cases?
Grahame Grieve (Mar 14 2018 at 19:19):
you can't distinguish the case. There's no computable way to define what's reasonable here, especially since what's reasonable depends on context outside the instance. We've known this since long ago in the v3 process (2005, I think the first discussion about this was)
Grahame Grieve (Mar 14 2018 at 19:20):
so the discussion has wandered away from the topic, which had 2 parts, really:
- is it ok for a component observation to have a code that is subsumed by a code in the root observation
- what should we do about subsumption in fhirpath?
Grahame Grieve (Mar 14 2018 at 19:23):
after thinking about the 2nd question for a few hours, the answer is: define a standard API to the terminology service that is available in FHIRPath.
iff(terminologyService().subsumes(concept1, concept2) = 'subsumes', ....
Grahame Grieve (Mar 14 2018 at 19:24):
so the answer is: this is a FHIR question, not a FHIRPath question, and FHIRPath shouldn't do anything about this. I'll create a task for documenting a standard terminology service API in FHIRPath
Bryn Rhodes (Mar 14 2018 at 19:24):
Well I was hoping to get to a resolution on the second part there by saying we didn't need it because CodeableConcepts wouldn't ever contain it. But it sounds like that's not reasonable, so we either define it in the spec, or.... I see you beat me to it.
Grahame Grieve (Mar 14 2018 at 19:27):
Michael Lawley (Mar 17 2018 at 03:08):
@Bryn Rhodes definitely does not imply cross system "equivalence", but only cross system relatedness
.
Michael Lawley (Mar 17 2018 at 03:13):
I think there's still an open question of subsumption between CodeableConcepts? ie when one or the other has (or both have) > 1 code
Grahame Grieve (Mar 17 2018 at 09:33):
well, we know that you could be in the situation where 2 codeable concepts both have codes, and thereby they both subsume each other. This would obviously be a non-sensical situation, but we should expect that this will happen somewhere some time.... but I don't think that we need to rule about situations like this in the spec
Lloyd McKenzie (Mar 17 2018 at 14:41):
Why would it be nonsensical?
Michelle (Moseman) Miller (Mar 19 2018 at 13:47):
Sorry I'm late to the discussion, but I wanted to follow up on the earlier comment from @Rob Hausam
I would not expect or recommend including codes for both "Blood Pressure" and "Blood Pressure-sitting" as translations (assuming that they're from the same code system)
That seems to conflict with the Vital Signs profile, which says:
If a more specific code or another code system is recorded or required, implementers must support both the values (LOINC) listed below and the translated code - e.g. method specific LOINC codes
Even outside of Vital Signs, Pharmacy has guidance for Medication.code as follows:
Other codes can only be literal translations to alternative code systems, or codes at a lower level of granularity (e.g. a generic code for a vendor-specific primary one).
That reads as if it is OK for us to send multiple RxNorms with differing term types (e.g. ingredient/generic + brand) as coding translations of the same CodeableConcept.
Grahame Grieve (Mar 19 2018 at 18:08):
the question here is different: not "should codes with different granularity be found on Observation.code" but "should codes with different granularity be spread across Observation.code and Observation.component.code"
Michelle (Moseman) Miller (Mar 19 2018 at 21:14):
Yeah, that was your initial question, @Grahame Grieve , but then the discussion seemed to get side tracked with whether multiple codes with differing granularities from the same code system were allowed translations (and I'm saying yes, that does happen in our implementation).
Going back to your initial question, I believe my old tracker GF#9375 introduced the invariant obs-7 cited in GF#13451. In our original use case, the Observation.code = Observation.component.code to support SHx multi-valued answers to a single question.
Our other use of components (beyond multi-valued answers) is Vital Signs, but I don't think we'd say SBP (component) is a more granular representation of the BP panel (code)...rather the component is part of the panel. Just speaking for our implementation, I think an equivalence check is sufficient.
Grahame Grieve (Mar 19 2018 at 22:58):
Well I think that in general, it would be wrong for the component code to subsume the code (or vice verse) - but I’m for from convinced that we can make a hard rule that this is always wrong.
Lloyd McKenzie (Mar 20 2018 at 00:29):
I'd love even one example where it would be right...
Grahame Grieve (Mar 20 2018 at 01:27):
ok:
Observation
code: [analyte]
value: [aggregate measure based on aggregate estimate from both methods]
component
code: [analyte by method1 ]
value: [result]
component
code: [analyte by method2]
value: [result]
Lloyd McKenzie (Mar 20 2018 at 01:28):
Thank you.
Eric Haas (Mar 20 2018 at 01:31):
I think that may be more common than you think.
Lloyd McKenzie (Mar 20 2018 at 01:36):
I'm not rejecting the use-case. It's sufficient to not prohibit components that are subsumed by the Observation. (Though it might be reasonable to prohibit the reverse - I don't think that component.code should ever be more general than the Observation.code
Grahame Grieve (Mar 20 2018 at 01:37):
probably but that sounds like best practice advice to me
Lloyd McKenzie (Mar 20 2018 at 02:17):
Best practice advice that's significantly different from Observation.code can't match component.code?
Grahame Grieve (Mar 20 2018 at 02:50):
best practice is that the code in Observation.code should not be subsumed by the code in Observation.component.code... and let us know if you think there's a valid case for that
Last updated: Apr 12 2022 at 19:14 UTC
