Stream: ontology
Topic: interpretation of multiple codings
Harold Solbrig (Jun 20 2016 at 23:43):
Going over the FHIR Meeting Report thread, I wasn't able to find a definitive conclusion besides "refer it to a committee". Question: Do I need to be able to understand all of the codings in a CodedConcept element in order to understand its intent? Will any one of them do? There are examples that appear to work both ways -- some which show a local coding system and what is assumed to be its equivalent in a standardized system. ( http://hl7-fhir.github.io/diagnosticreport-example-f202-bloodculture.json.html) In this case, I would think that the fact that I understand the SNOMED code for Laboratory Test would be sufficient. Yet there are other examples where multiple codes (sometimes from different coding systems) appear to be used as a poor man's compositional grammar. In this case, if I only recognize the codes from one coding system, my interpretation would either be too broad (fracture of the arm) or nonsensical (laterality left).
Grahame Grieve (Jun 20 2016 at 23:47):
where is an example of the latter? because it would be incorrect
Michelle (Moseman) Miller (Aug 31 2016 at 15:00):
I'm late to this discussion, but it seems to be a fair question.
Examples where the spec implies the different levels of granularity across the codings:
1) http://hl7-fhir.github.io/medication-definitions.html#Medication.code has a comment "Depending on the context of use, the code that was actually selected by the user (prescriber, dispenser, etc.) should be marked as "primary". 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)."
2) http://hl7-fhir.github.io/datatypes.html#CodeableConcept says "The different codings may have slightly different granularity due to the differences in the definitions of the underlying codes."
Rob Hausam (Aug 31 2016 at 15:26):
#2 just seems to be reflecting reality - the matches across code systems most often won't be "perfect" (even if the actual words are the same). #1, however, raises an interesting issue and could be problematic. If the use of Codings at different levels of granularity within a CodeableConcept is explicitly "sanctioned", then how far can (or will) that go - where are the boundaries?
I think it would be best, and safest, to stay with what I believe is implied by the CodeableConcept statement, that all of the Codings are intended to represent the same meaning (to the extent that is reasonably possible). Maybe we could more explicitly state that. And we could also explicitly state that intentionally coding at different levels of granularity, and, even more so, using multiple Codings to in some way "post-coordinate" the meaning, are not intended or sanctioned uses. And where there is a need to explicitly map concepts at different levels of granuality, that's best done with (and should be reserved for) ConceptMap.
Michelle (Moseman) Miller (Sep 01 2016 at 17:09):
@Rob Hausam , I agree that we shouldn't be post-coordinating the meaning.
In addition to the Medication example #1 above, I just stumbled upon another example in this discussion about race, https://chat.fhir.org/#narrow/stream/implementers/topic/slicing.20by.20value.20set, where it's being said that the codings can have different granularity for race (e.g. one of the 5 required for US reporting + greater granularity translations from the same coding system)
Grahame Grieve (Sep 01 2016 at 20:37):
translations shouldn't represent dfferent concepts to the user - e.g. if the user picks two different things, they shouldn't be put in translations.
Grahame Grieve (Sep 01 2016 at 20:38):
I think that applies in that siutation. but that's not a hard rule because sometimes putting them in translations is the only choice. Since that's driven by the granularity of the element itself rather than the concepts that go in i t
David Booth (Sep 20 2016 at 00:59):
@Rob Hausam I would think that there would be value in permitting additional codes that are broader or narrower than the originally selected code. A broader code in a different coding system might allow a code to be associated from that other coding system if no suitable narrower one exists. And a narrower code in a different coding system might allow the user to be more specific than the "preferred" coding system allows.
David Booth (Sep 20 2016 at 01:01):
What harm would you see in allowing broader and narrower codes to be associated? To my mind, the most straightforward semantics would be that all codes apply, i.e., they all accurately describe the situation, though some may describe the situation more precisely than others.
Grahame Grieve (Sep 20 2016 at 09:59):
you've just quoted our classic definition at the end there. But following my revised definitions ('the user picks two different things"), 'narrower than originally selected" is actually an edge case; the system probably shouldn't pick something narrrower, and if a human picks something narrower, it'll prbably be 'a different thing'. But neither of those things are absolutely true
Rob Hausam (Sep 20 2016 at 10:06):
My main question about that is, how far would you go with that - how much broader or narrower is "ok"? And since this is about an instance of a data type which represents the value of a coded element, we would have to designate which of the multiple codings in a CodeableConcept is the one that actually represents the meaning of the value. The others, at known and/or intended different levels of granularity, seem to be mappings to me - thus better suited for ConceptMap?
Grahame Grieve (Sep 20 2016 at 10:18):
well, denormalised out of concept map
Grahame Grieve (Sep 20 2016 at 10:19):
what we've said up to now is that if they are provided as a set of codings (or as translations) then they all represent the meanng of the value
Grahame Grieve (Sep 20 2016 at 10:20):
that actually works better in FHIR because if one of them is distinctly a classification rather than a coding (happens) you can put it an extension next to the coded element (much harder in CDA or v2)
David Booth (Sep 20 2016 at 14:19):
I think the question of 'how much broader or narrower is ok' is always going to be there, no matter how this is approached. I think it's one of those things where we can provide best practice guidance, but ultimately it is up the user's judgement call. I don't see any way that we can escape that.
David Booth (Sep 20 2016 at 14:22):
@Grahame Grieve I agree that the system should never pick something narrower (unless it somehow has access to other information to indicate that it would be accurate). Only the human user should do that, and it probably would be rare.
Grahame Grieve (Sep 20 2016 at 15:12):
yes the system can have other information e.g. from a sibling element
David Booth (Oct 11 2016 at 15:44):
What about equivalence between a pre-coordinated LOINC code, and its equivalent as SNOMED post-coordinated terms. How should the SNOMED post-coordinated terms be represented in FHIR? As a single Coding (using SNOMED's post-coordination notation)? Or as multiple Codings? What if multiple Codings are required for post-coordination in other coding systems, like CPT? Do these use cases mean that multiple codings *should* be permitted to be interpreted as post-coordination? If not, how do we draw the line?
Grahame Grieve (Oct 11 2016 at 19:13):
multiple codings are not to be interpreted as post-coordination. For snomed, you would use an expression.
Grahame Grieve (Oct 11 2016 at 19:13):
CPT - the subject has never come up (and CPT support is problematic because of AMA licensing terms)
Rob Hausam (Oct 14 2016 at 22:42):
I agree with @Grahame Grieve about using SNOMED CT compositional grammar expression in a single Coding to represent post-coordination. But @David Booth is describing a real use case for other coding systems. With CPT there is the issue of needing to add required modifers to the base code for certain situations (like -25 for “Significant, Separately Identifiable Evaluation and Management Service by the Same Physician on the Same Day of the Procedure or Other Service"). But I think it's even more of an issue with ICD-10-CM (and probably with "base" ICD-10, too, although I haven't checked that).
Rob Hausam (Oct 14 2016 at 22:44):
Here’s some relevant text from the ICD-10-CM Official Guidelines for Coding and Reporting:
7. Multiple coding for a single condition
In addition to the etiology/manifestation convention that requires two codes to fully describe a single condition that affects multiple body systems, there are other single conditions that also require more than one code. “Use additional code” notes are found in the Tabular List at codes that are not part of an etiology/manifestation pair where a secondary code is useful to fully describe a condition. The sequencing rule is the same as the etiology/manifestation pair, “use additional code” indicates that a secondary code should be added.
For example, for bacterial infections that are not included in chapter 1, a secondary code from category B95, Streptococcus, Staphylococcus, and Enterococcus, as the cause of diseases classified elsewhere, or B96, Other bacterial agents as the cause of diseases classified elsewhere, may be required to identify the bacterial organism causing the infection. A “use additional code” note will normally be found at the infectious disease code, indicating a need for the organism code to be added as a secondary code.
“Code first” notes are also under certain codes that are not specifically manifestation codes but may be due to an underlying cause. When there is a “code first” note and an underlying condition is present, the underlying condition should be sequenced first.
“Code, if applicable, any causal condition first”, notes indicate that this code may be assigned as a principal diagnosis when the causal condition is unknown or not applicable. If a causal condition is known, then the code for that condition should be sequenced as the principal or first-listed diagnosis.
Multiple codes may be needed for sequela, complication codes and obstetric codes to more fully describe a condition. See the specific guidelines for these conditions for further instruction.
Rob Hausam (Oct 14 2016 at 22:54):
I'm actually somewhat surprised that this hasn't come up before. Thinking about how to handle the ICD-10-CM multiple codings, there isn't a formal post-coordination syntax, but there are rules, which at least require the proper sequencing. I'm thinking that in this case the multiple codes probably should be represented in a single Coding.code element (within a CodeableConcept typically), with the individual ICD-10-CM codes separated by whitespace (e.g. space or comma). At the moment I don't really see any other likely way to represent the intent. Maybe we will need to define the post-coordination syntax for ICD-10 (in its various flavors), since they don't?
Rob Hausam (Oct 14 2016 at 22:54):
We also probably need to move this discussion to the terminology stream.
Grahame Grieve (Oct 14 2016 at 23:06):
it has come up before; We will follow the ISO 21090 ICD combination syntax, but we will make it a base part of the code system in FHIR
Grahame Grieve (Oct 14 2016 at 23:06):
though I see we do not document this. Could create a task to document it
Rob Hausam (Oct 15 2016 at 01:36):
Done - GF#12278.
Michael Lawley (Oct 16 2016 at 23:15):
Have you got a link pointing to "ISO 21090 ICD combination syntax" - I've googled but no joy other than large multipage documents that I can't search
Grahame Grieve (Oct 16 2016 at 23:23):
http://www.hl7.org/oid/index.cfm?Comp_OID=2.16.840.1.113883.6.260
Michael Lawley (Oct 17 2016 at 00:13):
Thanks!
David Booth (Oct 25 2016 at 18:28):
So, to close the loop on the original issue, it seems that we are in agreement that multiple codings in a CodeableConcept should not be used for post-coordination. And to return to @Harold Solbrig 's original question, "Do I need to be able to understand all of the codings in a CodedConcept element in order to understand its intent?" the answer is no. Each of the codings independently conveys the intent, though the specificity may vary somewhat. Correct?
Lloyd McKenzie (Oct 25 2016 at 19:08):
Correct. One of the codings may be marked as the one the original user selected/entered which may give it a bit of primacy, but it's fine to ignore that one and only look at one of the others.
Rob Hausam (Oct 28 2016 at 18:22):
Agree.
Last updated: Apr 12 2022 at 19:14 UTC
