Stream: terminology
Topic: smoking status
Jay Lyle (Aug 31 2018 at 13:55):
Argonaut follows MU in labeling "77176002 |Smoker (finding)|" as "Smoker, current status unknown." Does this mean "We don't know how to assign one of the more specific MU codes," or does it actually change the meaning of the code? Which label should be sent? (and can I cross-post this to Argonaut thread?)
Michael Lawley (Aug 31 2018 at 14:18):
Current smoker is a synonym so I'd argue that it's changing the meaning.
Rob Hausam (Aug 31 2018 at 18:32):
I suspect that what was intended (at least originally) by that description is something like "this person is a smoker - and that's all that we know". But I'm not certain about that, and the way it is stated makes an interpretation of "we don't know if this person is currently a smoker" pretty likely (if not inevitable). But even adding the notion of unknown to it at all is a change in meaning, so I agree with Michael. This is a problem and it should be changed. If that description is used at all it would have to be in CodeableConcept.text (although, as just mentioned, that isn't a good idea). But since it isn't from SNOMED (the US or International Edition) it isn't allowable at all in Coding.display - the only terms that are allowed there are the SNOMED CT synonyms "Smoker" and "Current smoker". The best way (and the only way, I think) to cross-post is to post the link to the discussion in this topic (here) also as a new topic in the Argonaut stream, or to move the discussion there and post the link to that topic back here.
Robert McClure (Sep 01 2018 at 02:10):
@Jay Lyle , where do you get the "follows MU" part? Where does "MU" say this? As for Argonuts - well, there you are.;.
Eric Haas (Sep 01 2018 at 05:40):
@Robert McClure "2015 Edition Certification Companion Guide
2015 Edition Common Clinical Data Set - 45 CFR 170.102"
Jay Lyle (Sep 01 2018 at 13:13):
Thanks, all.
1. The SCT code means current (or at time of record), as Michael points out.
2. The Argonaut list also contains children of Smoker, including occasional, light, daily, and heavy smoker. Within that context, "status unknown" seems (to me) to mean "intensity unknown"--like NOS. (I have yet to find a use of "status" I'm really happy with.)
3. Proposed answer: Since the Coding requires the SCT description, we'll use that in Coding, and since we're inferring it (from health factors), the CodeableConcept.text gets the original text, and the Argonaut label has no place in the instance, so it can't confuse the recipient. Based on 1 & 2, this is good. Cross-posting to Argonauts.
Rob Hausam (Sep 01 2018 at 13:19):
I'll just add to be sure that whenever this code is used that the intended meaning is "Current smoker", without any further specialization, and it doesn't mean that the smoking status (current or otherwise) is "unknown".
Jay Lyle (Sep 02 2018 at 22:42):
Agreed. And the data type, fortunately, prevents the introduction of confusion into the instance.
Eric Haas (Sep 04 2018 at 00:34):
How do we know what the recipient want? the regulatory text or the SCT description?
Brett Marquard (Sep 04 2018 at 12:48):
Reminder, any time we talk Argonaut/US Core the same data element is also in C-CDA.
Robert McClure (Sep 04 2018 at 21:36):
@Brett Marquard Actually while the element is "the same" the issue here is that the 2015 CCDS published by ONC broke a cardinal rule in the document published here by changing the text of the description of code "Smoker" (77176002) to mean something different. Luckily anyone that downloads a value set from a reputable source (;-) should not get that description, they will get the official one. Unfortunately, US Core followed suit in copying that into the display here, as did Argonaut here. I'll note that each of these is a different value set, with a different defining url. I'm hoping that most FHIR terminology servers will not include that improper description, and just return "Smoker". I'm trying to test that now...
Jay Lyle (Sep 11 2018 at 21:55):
Related question: coding states regarding display: "The display is a text representation of the code defined by the system and is used to display the meaning of the code by an application that is not aware of the system." Is there any constraint that it must be a particular representation? SCT has "Anesthetics"; we'd like to use synonym "Anesthesiology."
Grahame Grieve (Sep 11 2018 at 22:01):
well, you are allowed to override the display in a value set, but not in a Coding - there, it must be a valid display as defined in the code system; you use CodeableConcept.text instead
Rob Hausam (Sep 11 2018 at 22:09):
It can be any valid SNOMED CT synonym for that concept (although it should be available in the edition/version that you're using, of course). Normally it's best for it to be the 'Preferred' term in the language reference set that you (and the server) are using. In this case that's "Anesthetics", but "Anesthesiology" is an 'Acceptable' synonym term in SNOMED CT (I assume you're using the US Edition) and therefore it's acceptable to use it for this concept in Coding.display, too.
Michael Lawley (Sep 12 2018 at 00:22):
Interesting - "Anesthesiology" is not an acceptable term for 394577000 | Anesthetics (qualifier value) | in SNOMED CT-AU
Michael Lawley (Sep 12 2018 at 00:23):
@Grahame Grieve did you mean to say that the Coding.display must match the display of code as determined by the ValueSet (as opposed to the CodeSystem)?
Grahame Grieve (Sep 12 2018 at 00:23):
no I didn't mean to say that
Michael Lawley (Sep 12 2018 at 00:24):
So a ValueSet bound to a Coding cannot change the display text for a code?
Grahame Grieve (Sep 12 2018 at 00:25):
no and there's a dislocation here: the value set can specify a different display for the drop-down, but you have to use the code system display in the Coding that results from that
Jim Steel (Sep 12 2018 at 00:26):
Ew
Jim Steel (Sep 12 2018 at 00:27):
So the clinician may have been selecting different text, and there's no way to record that (if its a Coding)?
Grahame Grieve (Sep 12 2018 at 00:31):
not if it's a coding. but you should never have a coding where that would arise. And if you find one, it's a design error in the resource (or possibly the profile)
Grahame Grieve (Sep 12 2018 at 00:31):
our guidance is: you should never use a Coding directly unless you are very sure about the limitations on it's use
Jim Steel (Sep 12 2018 at 00:32):
It seems like a way to clarify/enforce that would be to explicitly say that you should never bind a Coding-typed field to a ValueSet that overrides display text/s
Michael Lawley (Sep 12 2018 at 00:36):
ImagingStudy.series.bodySite ?
What about alternate displays that come from a CodeSystem.supplement?
Jim Steel (Sep 12 2018 at 00:37):
He said the 's' word. 20c in the swear jar.
Grahame Grieve (Sep 12 2018 at 01:29):
supplement defined displays are in the code system
Grahame Grieve (Sep 12 2018 at 01:30):
Agree to say that you should never bind a coding type element to a value set that defines displays not in the code system
John Moehrke (Sep 12 2018 at 15:28):
so following this thread, it would see a CR needs to be filed against ImagingStudy for the various elements that are Coding that should be CodableConcept?
Rob Hausam (Sep 12 2018 at 22:48):
Yes, I think that's a reasonable conclusion, John. The Coding instances in ImagingStudy are all Extensible or Example bindings and they don't seem to meet the guidance of "The Coding data type is used directly when there is certainty that the value must be selected directly from one of the available codes, and the list of possible codes is agreed to by all participants".
Simone Heckmann (Jan 07 2019 at 15:11):
In the US Core Profile, the LOINC Code 72166-2 is used for Observation.code.
However, Observation.value binds to a SNOMED-ValueSet rather than the "normative answer list" documented with this code
https://s.details.loinc.org/LOINC/72166-2.html?sections=Comprehensive
Isn't there an expectation that if you use a LOINC code for Observation.code that Observation.value should conform to the LOINC answer list?
Rob Hausam (Jan 07 2019 at 16:18):
@Simone Heckmann No, there isn't any expectation like that from LOINC or HL7 or elsewhere, as far as I know. The availability of LOINC answer list codes is somewhat more recent, and I believe that US Core is following the more longstanding notion that "LOINC is the question and SNOMED is the answer". None of that is absolute. I'm sure that LOINC is quite happy for the LOINC answer codes to be used, but there isn't a specific expectation or requirement about it. It's up to the particular IG regarding what is done for this, and I don't see a problem with the way that it is specified in US Core now.
Simone Heckmann (Jan 07 2019 at 16:22):
Thanks Rob!
Robert McClure (Jan 10 2019 at 22:35):
Actually @Simone Heckmann I think it's more complicated than that. The smoking status code you cite is actually used by Dan in his blog here which says:
Normative lists are those specifically defined by a validated instrument or other authoritative source. Basically, if you want to use this LOINC term, you have to use exactly this set of possible answers.
Now I think many of us (@Daniel Vreeman ?) think that we can use exactly aligned SNOMED CT codes that match the answers.
Rob Hausam (Jan 11 2019 at 02:57):
@Simone Heckmann @Robert McClure does raise a good point. Dan's blog post at least appears to be stating this considerably more stringently than I described, but the post doesn't mention SNOMED, including how LOINC and SNOMED are to be used together, and I'm not entirely certain how the guidance is to be transferred to that situation. But the post does state clearly that you must pay attention to the method, and if a code specifies a particular assessment method and a normative answer list, as this one does, then you should either use those exact answers or you should be using a different code. In this case, the SNOMED CT value set that US Core binds to does have codes for the exact same 8 answers (even with a slight display term difference shown in US Core for 2 of the codes, the US edition preferred term synonym for those codes is identical to the LOINC term) - so I think that follows Dan's guidance just fine. What I did notice that is slightly different, though, is that US Core has an extensible binding to the value set rather than a required binding (which the LOINC normative answer list likely would imply) - so potentially other answer codes outside of the value set could be used in an instance of this US Core Observation profile which would not be in accord with the LOINC guidance or the instrument it is based on. I think it would be good to clarify this a bit further with @Daniel Vreeman in San Antonio.
Stefan Lang (Jan 11 2019 at 04:01):
Please ping me when discussing this in San Antonio.
This looks very important to me, especially since I also follow the best practice Rob mentions (LOINC is the question, SNOMED, or some other code system in non-SNOMED regions of the world, is the answer).
This may also affect IGs across all technologies, not only FHIR. Therefor I'd like to ping @Julian Sass (not fully sure he'll be at the WGM)
Rob Hausam (Jan 11 2019 at 19:19):
@Stefan Lang I expect some discussion will occur impromptu, but we can definitely do that.
Daniel Vreeman (Jan 15 2019 at 12:07):
Hi all...a quick bit of background. LOINC's answer lists can be either intensionally or extensionally defined. When we enumerate the possible choices, we use LOINC Answer codes (string identifiers) as the main ID for the allowed options. In the context of that list, we also often provide the local "label/code" for that choice as it appears on the form (often 1,2,3,4 or A,b,c,d, etc). We can also provide mappings to other codes (e.g. from SNOMED CT) where we have them and is allowed by licensing. Ok, for normative lists, as described in the LOINC Users Guide (and in my blog post), we say that to use a LOINC term with a NORMATIVE bound answer list you must be using that term in the same manner as specified by the list. I.e. you must have the same possible answer set (with the caveat about Null Flavors). It is NOT required that you use the LA (LOINC Answer) codes to identify the response values when exchanging/storing data. From the LOINC perspective, you could use no codes (just text), local codes, LA codes, exactly equivalent alternate codings, or some combination of all these and it would be fine. Your choice about this may be influenced by many factors. But, for example, using exact match SNOMED CT concepts would work. There are cases where that might be the best choice, and there are other cases (terms/lists) where there are no corresponding SNOMED CT concepts, and/or you want to capture the exact answer choice as it appears on the form, and/or there are licensing issues you want to avoid, where the LA coded answers may be your best choice. One last note about this particular term is that it represents the question of smoking status as defined by the CDC's NHIS instrument and is very widely used. (These answers were the categories MU defined/required, so fits that context). It sounds like a great choice for use in US Core, but it would not be valid to use a different set of smoking status categories as the allowed answer set when using this LOINC observation code. Hope this helps...happy to discuss more if needed.
Rob Hausam (Jan 15 2019 at 12:29):
Thanks, Dan. Can you clarify how this should apply when there is a binding to a value set containing a set of SNOMED CT codes exactly matching the answer list (so that's good), but the binding is extensible rather than required, so there is a possibly that other codes outside of that answer list and value set could be used? I think based on what you've said (in the blog and here) that isn't allowed. So, if that's the case, then I think that US Core will need to change that binding strength?
Eric Haas (Jan 15 2019 at 16:15):
it is listed as extensible + max valueset binding which mean required but text only allowed. The publishing framework doesn't reflect those nuances.
Grahame Grieve (Jan 15 2019 at 17:09):
make a task...
Eric Haas (Jan 15 2019 at 21:01):
BTW ... I was not criticizing the tool nor expecting it behave differently, this is edge case stuff and I document these bindings in the guidance but probably could do a better job on that.
Rob Hausam (Jan 16 2019 at 02:51):
Makes sense. But as I understand the LOINC guidance we've been looking at, if you extend the value set at all then you can't use that LOINC code. So the max and min value set would need to be the same (which is certainly a rather obscure way to do it) or the binding would need to be required instead of extensible.
Eric Haas (Jan 16 2019 at 12:13):
@Rob Hausam I think you need to look at max value extension again. this is only way to make a required binding or text only option. So for a required binding for valueset consisting of concepts ['foo', 'bar'] you can only have 'foo' or 'bar' codes and no text only in a Codeable element. so "my_codeable_element": {"text" : "my text only repr of element"} would be invalid. With the magic of the max value extension. You get your cake and eat it too because you get the extensible binding functionality of allowing the text only as valid representation of my_codeable_element but have locked down the extensible binding to the max number of values within the Valueset like a required binding.
Rob Hausam (Jan 16 2019 at 12:18):
Ok, I see what you're getting at, Eric, regarding preserving the text only option. I hadn't tried to verify that the min and max bindings were indeed the same, but that makes sense. It is a little kludgey that we have to do it this way, though (but that is not in any way your fault). It would probably be difficult to do anything to change it now, but it could be nice to find a somewhat more explicit and clear option for specifying this.
Eric Haas (Jan 16 2019 at 12:30):
The alternative is to create a bunch of new bindings ( I think if you are looking at elementdefinition you passed obscure a while ago.) I agree that to really be required need to have both minValue = maxValue. In US Core only have MaxValue and that may be the intent, I forget and need to go in the way back machine and look at my notes, since we discussed this at length.
Last updated: Apr 12 2022 at 19:14 UTC
