Stream: terminology
Topic: Extensible
Grahame Grieve (Dec 22 2016 at 20:27):
ok. I would like to add to the vocab agenda in San Antonio the need for an extension that you speicfy on binding when the binding strength is extensible, to say whether the extension is allowed to be by code, by text, or by either.
Rob Hausam (Dec 22 2016 at 22:10):
I get what you're asking for, but I'm not sure if it's something that we actually need (you're welcome to persuade me that it is). Since the CodeableConcept.text is "A human language representation of the concept ...", I think that code and text go hand in hand, and I don't see a reason to make a distinction between them in regard to an extensible binding.
Grahame Grieve (Dec 22 2016 at 22:14):
then you should read the long thread about this in the argonaut stream; they didn't want to use extensible as it is because they didn't want a different code provided in place of the recommended code, but they did need to be able to fall back to plain text
Grahame Grieve (Dec 22 2016 at 22:14):
but we had also in past discussed the opposite: the need to say that the thing must be coded - can't fall back to text
Rob Hausam (Dec 22 2016 at 22:27):
I'll read the argonaut thread - hadn't done that yet
Eric Haas (Dec 22 2016 at 22:31):
The need has been expressed by all the argonaut implementers and is where regulations and reality collide.
Rob Hausam (Dec 22 2016 at 22:52):
I don't know exactly what that means, Eric - but I can read the thread if that explains it
Grahame Grieve (Aug 10 2018 at 02:03):
so I am looking at GF#14865 - which says that an extensible binding may be extended with concepts that have an is-a relationship with concepts in the value set, if the desired meaning to be represented is not present in the specified value set - and that we'll add some examples
Grahame Grieve (Aug 10 2018 at 02:04):
well. I don't know how something can have a meaning that's not in the value set if it has an is-a with a code in the value set. Alternatively, I don't understand what anyone thinks the point of an extensible value set is if it doesn't mean anything after all.
Grahame Grieve (Aug 10 2018 at 02:05):
and so therefore I cannot imagine what example I'd be adding...
Grahame Grieve (Aug 10 2018 at 02:05):
and this disposition is not at all consistent with what we've said before which is:
Grahame Grieve (Aug 10 2018 at 02:05):
To be conformant, the concept in this element SHALL be from the specified value set if any of the codes within the value set can apply to the concept being communicated.
Grahame Grieve (Aug 10 2018 at 02:06):
and
Grahame Grieve (Aug 10 2018 at 02:06):
but if no suitable code exists in the value set, alternate code(s) may be provided in its place
Grahame Grieve (Aug 10 2018 at 02:06):
I think there's an subtle important difference in meaning between 'no suitable code' and 'the desired meaning to be represented is not present'
Lloyd McKenzie (Aug 10 2018 at 02:09):
Agree that doing this would be very problematic. If the value set contains "blue", there are no circumstances where you'd be allowed to extend the value set with "navy blue".
Rob Hausam (Aug 10 2018 at 02:33):
I think the main problem that led to this is that we're not really clear in the spec about the "can't use 'navy blue' if 'blue' is in the value set" rule for extensible bindings, except in teaching the vocabulary tutorials (which is how I teach it). The meaning of "can apply to the concept being communicated" and "If the value set does not cover the concept (based on human review)" just isn't clear on that, without using more specific wording or specific examples (e.g. the "blue" and "navy blue", or others) to make it clearer. I think that's why we said in the resolution that "there is no restriction" (I don't know if I would do that again, but that's what we did). Like it or not, saying this "rule" a lot and teaching it in tutorials doesn't really make it binding as part of the spec. We should have actually made this clearer a long time ago. If we can skip applying the current resolution for the moment I would be happy to re-open this and make a different decision, but for sure make it really clear in the documentation.
Rob Hausam (Aug 10 2018 at 02:41):
Mark wasn't very clear in his tracker, either, but if I understand what he is asking it seems to me that using translations (assuming the data type is CodeableConcept) should work.
Lloyd McKenzie (Aug 10 2018 at 02:43):
I had added that particular example into the spec at one point but it got yanked for some reason.
Rob Hausam (Aug 10 2018 at 02:45):
I don't have a recollection of ever seeing it in the spec (but of course that doesn't mean it wasn't there). But I do know that I was never part of any discussion or decision to yank it.
Grahame Grieve (Aug 10 2018 at 03:08):
There is a situation where navy would be a valid extension, and that’s where there’s a secondary meaning in use. E.g. I assign colours to the kind of alerts that I have in the hospital, and have some special ‘navy’ alert that is different to blue alert. In that case (though it’s a bad idea), navy is not a specialisation of blue, even though by the literal meaning it is. Which is why I yanked it, because the language didn’t deal with that kind of subtlety
Grahame Grieve (Aug 10 2018 at 03:10):
I guess that on reflection I’m getting happier with ‘desired meaning to be represented is not present’ but I think it needs more clarity
Grahame Grieve (Aug 10 2018 at 03:10):
Something around essential meaning to being in the existing meanings. Of course, this comes down to judgement, but we already know that. So I think that any advice we provide has to be equivocal
Rob Hausam (Aug 10 2018 at 03:15):
I think I agree. But I also think we have to say clearly whether the "no subtype" rule is, in fact, required (even if we can't actually or very easily enforce it) or not. If it's just about the represented meaning, then 'navy blue' does in fact mean something that is different than 'blue', so on that basis it would be legitimate to use.
Lloyd McKenzie (Aug 10 2018 at 03:19):
"Desired meaning to be respresented is not present" is not tight enough. If I want to send the color navy blue, that's not allowed unless I also send the valueset code of "blue", regardless of what I might "desire".
Lloyd McKenzie (Aug 10 2018 at 03:19):
If extensible is based on "desire", it's no different from "preferred".
Rob Hausam (Aug 10 2018 at 03:24):
Extensible is always different from preferred (at least in theory). It depends on how we understand and scope "apply to the concept being communicated". If there is a code in the value set that "applies to the concept being communicated", then with an extensible binding you must use it, whereas with preferred that's not required. But "apply to" is much less precise than what we are wanting to say the rule is.
Rob Hausam (Aug 10 2018 at 03:26):
Of course we also say "cover", but I don't see that adding any useful precision.
Lloyd McKenzie (Aug 10 2018 at 03:27):
From a pure semantics perspective, if there's a concept in the valueset that is equivalent to or generalizes your concept, you must send the value set code for that concept.
Rob Hausam (Aug 10 2018 at 03:30):
I totally get that, and I more or less think of it and sometimes refer to that (and teach it) as "Lloyd's rule" (although I don't actually call it that). But I still maintain that the specification itself doesn't actually say that - even it we think we want it to.
Rob Hausam (Aug 10 2018 at 03:35):
And people who haven't heard you say it enough (whoever that might be?) and haven't taken one or more of the FHIR vocabulary tutorials very likely don't understand that it's supposed to be saying that.
Grahame Grieve (Aug 10 2018 at 03:44):
so perhaps we should add a section saying that in principle, the intention of defining an extensible value set is that implementers use one of those codes if applicble. There fore, implemeters SHOULD use one of those codes if possible. If more granularity is desired with more specific codes, these can be provided as translations. But because the exact use of code is highly variable, implementers can send a more granular code as an extensible code if desired meaning to be represented is not present and it is not safe to not include the meaning. Note that deciding which is a judgement call that may be equivocal.
Examples: blue/navy direct / indirect, hepatitis vs typed/staged hepatitis, and hepatitus vs contagious hepatitis with isolation required (though last example is off the top of my head, and there's probably a better disease to choose)
Lloyd McKenzie (Aug 10 2018 at 03:52):
Why would it be a SHOULD and not a SHALL? Your 'blue'/'navy' situation doesn't actually hold. If I'm using a code that means the color, then subsumption holds. If I'm using a code that means threat/alert level, then subsumption wouldn't hold. If we make it SHOULD, then people will send whatever they like and Extensible will have no meaning. The fact that it's hard to test in an automated fashion is no reason to be soft on the rule.
Lloyd McKenzie (Aug 10 2018 at 03:54):
If the value set says "hepatitus" then you cannot send "contageous hepatitis with isolation required" except as an additional coding to "hepatitus". That's the meaning of extensible.
Grahame Grieve (Aug 10 2018 at 03:55):
it can't be a SHOULD because (a) it's a judgement call and (b) you can't get enough agreement to the basic principle anyway
Lloyd McKenzie (Aug 10 2018 at 03:57):
If it's a judgement call whether concept A is a generalization of concept B, then in that case, you can't enforce the rule. But it's still the rule.
Lloyd McKenzie (Aug 10 2018 at 03:57):
The only individual who I've seen really fight against this is you :)
Lloyd McKenzie (Aug 10 2018 at 03:58):
There's certainly people who don't like things having extensible bindings because they want to send whatever they like - and they're welcome to fight the binding strength. But I haven't seen a whole lot of people who've had trouble with the meaning of it once it's been explained.
Grahame Grieve (Aug 10 2018 at 03:58):
I know you want it to be. Really bigly. But I just don't think that there's enough agreement in the community to make it so, especially when we look at the problems with is-a in real world terminologies, and especially classifications; is-a is often perspective based, and not everyone has the same perspective. that's why I think it should be a SHOULD
Grahame Grieve (Aug 10 2018 at 03:59):
if you want an example, you could look at the is-a relationships built into the clinicalStatus attribute, which make sense in that context, but that Snomed Intl won't agree are correct in the general case
Lloyd McKenzie (Aug 10 2018 at 03:59):
It has nothing to do with the terminologies. I'm not expecting it to be enforced by terminologies - it's going to be done by humans. Being done by humans who might sometimes get it wrong or disagree doesn't mean it's a should.
Rob Hausam (Aug 10 2018 at 04:00):
I know I keep beating the same drum, but if we really want this to be the rule (i.e. you can't use specializations - except as additional translation codes) then we actually have to say that in the spec first!
Lloyd McKenzie (Aug 10 2018 at 04:00):
The definition of all of our elements is going to be interpreted and applied by humans. And they'll sometimes get it wrong. But the definitions are still SHALLs. The meaning is the declared meaning.
Grahame Grieve (Aug 10 2018 at 04:00):
? if the terminology claims that it's is-a and it's not, because of perspective, then how can it be a SHALL? (and Rob, we're talking about what to say in the spec)
Lloyd McKenzie (Aug 10 2018 at 04:01):
If we want to note that sometimes codes get misused and that the "is-a" needs to be interpretted based on use, not terminology definition - and give your alert level colors as an example, I'm fine with that.
Grahame Grieve (Aug 10 2018 at 04:02):
hah I like that. [rule] SHALL be true (unless in your judgement, your use means it doesn't have to be)
Rob Hausam (Aug 10 2018 at 04:04):
Yes, I agree that's what we're talking about. Lloyd says that you are the only one who fights against this, but I don't think that's probably true. I think that Mark Kramer was fighting against it (if I understood him correctly). And a lot of others I think fight against it maybe more passively, by either not understanding or not really caring if they sort of do understand.
Grahame Grieve (Aug 10 2018 at 04:05):
no I think I'm not the only one. Who disagrees with SHALL and think it's SHOULD. Based on discussion last time this came up in committee
Grahame Grieve (Aug 10 2018 at 04:05):
If I was the only one, I'd give up
Lloyd McKenzie (Aug 10 2018 at 04:08):
If you're using codes intended to talk about the wavelength of reflected light to instead reflect what action to take in response to a "code" announcement, then your misuse of the code system means that subsumption relationships don't apply.
Lloyd McKenzie (Aug 10 2018 at 04:11):
The criteria there are pretty clear. If your concept corresponds to the code definitions and the is-a relationships are right, the rule applies. If the code system is broken or you're misusing the codes, then relying on code system subsumption isn't going to work, but human reasoning subsumption still will. If humans are going to disagree then they're going to disagree. Just as they might disagree whether something's appropriate as an Observation.category or whether it should be a translation of Observation.code. We don't say "data placed in attributes SHOULD comply with their definitions" though.
Rob Hausam (Aug 10 2018 at 04:13):
A while back I came to the personal conclusion that what the spec actually said and what was most likely to be understandable by most people was that if the meaning that you are looking for is in the value set (to some reasonable degree of approximation) then you are required to use the code from the value set, but if the meaning that you are looking for isn't in the value set (subsumption isn't a consideration) then you are free to use a different code. But I've been teaching it the other way, because that's what we've been doing. And it's definitely time to make it clear one way or the other.
Grahame Grieve (Aug 10 2018 at 04:18):
agree we should make it as clear as possible. And that it's the intent that you don't used subsumed codes. Else it doesn't makes sense to use extensible value sets in a code system that has is-a relationships. The question for me is SHOULD vs SHALL. But it's time for me to stop and see what other people say
Rob Hausam (Aug 10 2018 at 04:39):
I can accept the "no subsumed codes" rule - and I think it might actually have some real-world utility if it was understood and used consistently. So if we want to actually keep saying and expecting that, let's add the documentation that we need in 4.1.4.2 Extensible (and anywhere else it's needed) to actually say that. And once we've actually said that, then I think SHALL makes the most sense (if we use SHOULD then it really wouldn't be much different, if at all in practice, from preferred).
Richard Townley-O'Neill (Aug 10 2018 at 05:47):
I like the no-subsumption rule.
I like making the rule a shall, rather than a should. Though the rule is not generally testable, and consumers of resources cannot rely on it, making it shall allows readers/consumers of a resource to winge more forcefully to the creator of the resource when the rule is not followed.
Grahame Grieve (Aug 10 2018 at 23:42):
so I have not seen any support for SHOULD. I guess it's going to be a SHALL unless anyone objects. I believe that this one we have 3-4 more days before it's impossible not to change it... so there's a period for anyone to object
Michael Lawley (Aug 10 2018 at 23:58):
So I haven't heard the strict @Lloyd McKenzie interpretation before and have been working on a understanding very close to that expressed by @Rob Hausam . I'm all for a tight (clear) definition of this and agree with @Lloyd McKenzie that if subsumed codes are ruled out than that has to be based on the CodeSystem's position on subsumption (even if it's wrong or badly done).
But what I'm stuck with is understanding the why of all this -- why would you want navy blue to be excluded? It is clearly different to blue since it says "not royal blue", where as blue does not. So, if I'm trying to communicate that the colour is "navy blue and not royal blue (or any other blue)", then it would seem valid to say navy blue and yet this violates the no-subsumption rule.
Grahame Grieve (Aug 10 2018 at 23:59):
it's because of why extensible binding is being used. You're saying 'for this element, these concepts are the ones we agreed on, but you can use stuff outside that for other things'
Grahame Grieve (Aug 10 2018 at 23:59):
the question is, 'what are other things'. if we agree that the code for blue is 'blue', then under what grounds is royal blue something that is not blue?
Lloyd McKenzie (Aug 11 2018 at 00:07):
The value set is 'blue' then the expectation is that any color that qualifies as blue will be represented with that code. You can then safely build decision support and other logic on that knowledge. If we allow people to send any code for any slightly different concept, then suddenly we have no guarantee of consistency. If you have an ICD code that isn't exactly the same meaning as the SNOMED code in the extensible binding, you're suddenly free to send the ICD code instead. Decision support doesn't work, etc.
Rob Hausam (Aug 11 2018 at 00:17):
One question that I have is, have we seen anyone build decision support logic that relies on this understanding of extensible being a consistent and reliable basis for implementation? I haven't ever asked the CDS group about whether they do or would consider relying on it, but probably it would be a good question to ask. Personally, with my past experience and present leanings I would be much more likely to rely on the SNOMED CT hierarchy to build decision support logic based on terminology - but that assumes that I have access to and am using SNOMED CT. I wonder if anyone relies (or would rely) on this understanding with ICD or ICPC or something similar?
Grahame Grieve (Aug 11 2018 at 00:23):
not so much in heavy clinical areas, but definitely in other areas, where extensible value sets mean you can do switch statements .
Rob Hausam (Aug 11 2018 at 00:25):
Yes. So we have real examples that we can point to where that is being done?
Rob Hausam (Aug 11 2018 at 00:25):
although, of course, understanding that they may be proprietary
Robert McClure (Aug 11 2018 at 16:06):
1. I agree with Lloyd's rule, both because I have to live in his world :-P, and because I understand what he's trying to accomplish
2. If we don't follow a rule defining how Extensible is different from Preferred in a way that is in some way testable beyond what a single person thinks, I am not in favor of having Extensible as a binding strength at all.
Rob Hausam (Aug 11 2018 at 16:49):
We're updating the text so that it does state "Lloyd's rule" (and other things - examples still to be added), but it's still not going to be computably testable (except in some exceptional cases).
Robert McClure (Aug 11 2018 at 20:22):
I think we need to be clear - SHALL - that if a code system haas an is-a hierarchy any concept subsumed by a concept in the value set SHALL NOT be a valid member.
Rob Hausam (Aug 11 2018 at 23:01):
Can you clarify what is different about what you said from what is in the text (I assume you're referring to the text that I linked)? I can't really tell where you are suggesting to have the SHALL and SHALL NOT. The updated text that I wrote uses some different words, but so far I'm not seeing that any obvious meaning is different. I tried where I could to use relatively easily understood terms like "more general meaning" and "more specific meaning" and minimize use of terminology-specific phrases like "is-a hierarchy", and I managed to avoid using "subsumes" entirely. I think that should make it more rather than less clear and understandable for most of the implementer community who are the intended audience.
Grahame Grieve (Aug 11 2018 at 23:40):
I think Rob was responding to SHALL vs SHOULD
Michael Lawley (Aug 12 2018 at 00:37):
It sounds like the goal is to use the codes without relying on any subsumption. eg you want to rely on code equality in the logic and not code subsumption.
I'm not sure I buy the ICD SNOMED example because that's a case where there is no code system-defined subsumption and there's only overlap of meaning, which would then threaten CDS logic.
Michael Lawley (Aug 12 2018 at 00:41):
Doing hierarchy based stuff with ICD is of course fraught - there are all the exclusion criteria (but do you know if your data set used them or just used the surface meaning of the ICD codes), and then the NOC and NEC codes
Michael Lawley (Aug 12 2018 at 00:44):
The extensible rules appear to be framing an implicit other code with rules to establish its disjointness with the rest of the ValueSet.
Rob Hausam (Aug 12 2018 at 02:33):
@Grahame Grieve Yes, probably I was over-interpreting what @Robert McClure was saying. I think I focused in on the "we need to be clear" part and wasn't exactly sure about the rest.
Robert McClure (Aug 12 2018 at 18:28):
@Rob Hausam
I'd rather have the following changes:
1st paragraph :
To be conformant, codes in this element SHALL be from the specified value set if any of the codes within the value set represent, or generalize, the concept being communicated. If members of the value set expansion do not represent the concept (based on code system hierarchy membership, or human review), an alternate system/code from outside the value set (i.e. from a different value set or chosen from a code system directly) may be used instead.
3rd and 4th paragraph:
If there is a code in the value set expansion with a meaning which includes, but is more general than, the meaning that is desired for use, then the existing value set expansion member SHALL be used to represent the desired meaning. In this situation using a more specific code that more completely represents the intended meaning but is not included the value set expansion is not allowed. The more specific desired code may be included in the instance as an additional Coding if the data type is CodeableConcept, but it cannot be used instead of the code from the value set expansion. This helps ensure that systems can depend on interoperable exchange of the meanings (including more nuanced meanings) represented by codes in the extensibly bound expansion.
If the code system used by the value set defines a generalization hierarchy (is-a), the code system SHALL be used to determine if the desired code can be used. Any code from the code system that is more specific (in the hierarchy) to one included in the value set expansion cannot be used. In that case the concept from the extensibly bound value set expansion that is the closest match for the intended meaning of the element instance is the one that SHALL be used in the element instance.
Yes, I want this to explicitly discuss how generalization hierarchies can be used. I'll look at the examples if we agree with my modifications.
Rob Hausam (Aug 12 2018 at 18:39):
We still have a few days (up until Friday) where we're able to work on the specific wording if we need to do that. I'll read through your suggestions again. I believe that I agree with all of your intent, but I would like to make it slightly simpler and with a little more "implementer friendly" language in some places, if we can. I'll come up with something that we can look at and discuss on the tracker issues call tomorrow, and then we can see what we think. How does that sound?
Peter Jordan (Aug 13 2018 at 02:26):
As a (non-clinical) implementer, I find it difficult to understand why it should not be permissable to add a more specific concept to an extensible binding to a SNOMED CT-based Value Set. I'm not sure how this would defeat interoperability, whereas I do see how using a less specific concept might.
Furthermore, I'm not sure that 'hiding' a concept selected by a clinician at the point of care in the additional coding element of a CodableConcept data type is going to facilitate accurate recording and subsequent presentation of that clinician's selection.
As an example...
A ValueSet contains 22298006 |Myocardial infarction| but a clinician wishes to record 57054005 |Acute myocardial infarction|
It's a computationally trivial task for an analytics engine to link the (more specific) recorded concept back to the more general one found in the ValueSet
OTOH - if it's permissible to select a more general concept, e.g. one of its 4 parent concepts such as 57809008 |Myocardial disease|, it might not be safe for another application to map this back to a more specific concept contained in the Value Set
However, as ever, I'd be happy to be corrected by a professional terminologist and there's a beer waiting in Baltimore or Vancouver for anyone who can enlighten me!
Rob Hausam (Aug 13 2018 at 02:40):
Reasonable points there. A comment: Probably if we're talking about an intensionally defined SNOMED CT value set all of the available pre-coordinated concepts will be included so 57054005 |Acute myocardial infarction| would be in the value set and it wouldn't be a problem to record it. If the concept was a more specific compositional expression then that might not be "in" the value set (at least for this purpose), so that could be a different matter. And one correction: The point of saying "the code for the concept in the value set that applies to and is the closest match for the intended meaning of the element instance is the one that should be used" (emphasis added) is that choosing a more general concept is not intended to be permissible - but maybe to make that clear enough it needs to be SHALL rather than "should".
Lloyd McKenzie (Aug 13 2018 at 02:41):
The whole purpose of "extensible" is providing high confidence about how certain concepts will be represented. If I know that pneumonia will always be represented with the same code, regardless of type, severity, onset, etc., I can dramatically simplify my software. Interoperability is enhanced. If implementers are allowed to send any code they like if their degree of precision differs even slightly from the standard code, interoperability goes out the window.
Lloyd McKenzie (Aug 13 2018 at 02:41):
Nothing stops you from sending whatever SNOMED concept you like with whatever qualifiers you wish to get to the most precise representation of your concept. All extensible says is that you must also send the standard concept.
Rob Hausam (Aug 13 2018 at 02:43):
Correct - I tried to show that in the fourth example.
Peter Jordan (Aug 13 2018 at 04:13):
@Lloyd McKenzie - my impression, thus far, in speaking to SCT implementers in NZ is that, for a variety of reasons, they wish to present the most atomic concepts possible to clinicians without qualifiers. Most significant is the push-back if they attempt to effectively limit the vocabulary; then there is also the fact that attempting to obtain precise meaning by combining a general concept with other attributes is actually more complex, and less likely to lead to interoperable outcomes, than selecting the most specific pre-coordinated concept available in the terminology itself.
Lloyd McKenzie (Aug 13 2018 at 04:20):
They can send whatever they like. But if someone puts an extensible binding on something and chooses to constrain to specific SNOMED concepts (which isn't a super-likely scenario), they'll have to send the codes from that value set too if they apply.
Lloyd McKenzie (Aug 13 2018 at 04:21):
Because that design decision would be based on the expectation that at least some implementers would not understand how to do SNOMED subsumption and wouldn't be required to do so - either themselves or through a terminology server. (If that wasn't the assumption, then you wouldn't bother enumerating the SNOMED codes.)
Lloyd McKenzie (Aug 13 2018 at 04:24):
It's much the same premise as what's been done with vital signs. You SHALL send the specified LOINC code in the profile that says "blood pressure". If you want to send a more refined one too to convey "sitting blood pressure", you can. But you're not allowed to send that instead. That means that SMART apps and others have a guaranteed reliable way to grab all blood pressures without having to worry about all the numerous ways it might potentially be coded or having to support code translations and subsuption - because asking an iPhone app to manage that is unrealistic.
Richard Townley-O'Neill (Aug 13 2018 at 04:29):
While saying 'navy blue' with the no-subsumption rule involves sending two codes (e.g. coding.code=Blue + coding.code=Navy Blue). This simplifies searching and machine processing. It does make display messier, showing the codes will show both 'blue' and 'navy blue'.
Saying 'navy blue' without the no-subsumption rule involves sending one code (e.g. coding.code=Navy Blue). This (vastly) complicates searching and machine processing. It does make showing the codes neater, it shows only navy blue.
However, if the data element is CodeableConcept, the CodeableConcept.text can contain just 'navy blue', especially if that is what the author entered. So the desire for a simple display is not a problem.
Lloyd McKenzie (Aug 13 2018 at 04:35):
Display logic is going to have to deal with multiple codes for all sorts of reasons, not just for this extensible binding situation. It should try first to grab CodeableConcept.text and if that's not around, it should grab the display for the user-specified coding. If that's not there, then it'll have to have other logic to decide what to display.
Peter Jordan (Aug 13 2018 at 04:50):
In an ideal SCT implementation world of intensional reference sets, both Rob H and Lloyd would be correct in noting that this might be an academic discussion. However, in reality National Release Centres in NZ (plus the UK and Australia from what I gather from the SNOMED on FHIR calls) are publishing extensional reference sets which, if/when bound to FHIR data elements will be problematic if they cannot be augmented by more specific concepts. As an international edition example, one just has to look for certain key antenatal concepts in the GP/Family Practice Reference Set. Without subsumption, SCT would be just another coding system for NZ and the business case for using it to replace Read Codes in primary care would be diminished - quite substantially.
Lloyd McKenzie (Aug 13 2018 at 04:54):
It's not going to cause "problems" - more detailed codes can still be sent. But the high level codes must also be sent.
Lloyd McKenzie (Aug 13 2018 at 04:55):
If that outcome isn't acceptable, the solution isn't to push back on HL7's definition of extensible, it's to push back on either the way the value sets are being defined as extensional or the use of extensible or both.
Peter Jordan (Aug 13 2018 at 05:20):
I'm pushing back, as hard as I can, on the use of extensional value sets. However, for SCT, I still don't like the idea of using coded data types to repeat relationships between concepts that are already present in the properties of the selected concept itself. Having typed that I will be prepared to change my view IF it's not shared by the implementer community I deal with on a regular basis here in NZ.
Lloyd McKenzie (Aug 13 2018 at 05:33):
I don't think anyone's talking about repeating relationships. We're talking about expressing coded data at multiple levels of granularity and possibly with different code systems. The need for that is going to be driven by the fact that different consumers of data are frequently going to specify different value sets with granularities that are driven by the use-case. Unless there's massive support for subsumption testing and high-quality translation across code systems (which given the terminology capabilities of most systems, seems very unlikely), sending multiple codings is going to be exceptionally common.
Rob Hausam (Aug 13 2018 at 05:40):
Partly as a result of this further discussion, I've made a few additional (relatively minor) updates to the extensible binding text and logic description, so take a look. Hopefully I'll be able to stop making updates soon. :)
Michael Lawley (Aug 13 2018 at 05:50):
FWIW I believe that the Digital Health Agency here in Australia has a policy of not using Extensible bindings.
Michael Lawley (Aug 13 2018 at 05:56):
Pushing on the examples a little for full clarity, let us assume an Extensible binding to a LOINC ValueSet that includes sitting blood pressure but not blood pressure. Is it then ok to use blood pressure (if it's not known to be sitting)?
Michael Lawley (Aug 13 2018 at 06:03):
BTW I don't buy the arguments that subsumption testing is hard for any of these cases (unless you've got SNOMED post coordination in play). The search API provides for code:below and $subsumes and $closure both allow for externalising the test.
But, I think the strongest argument here is the problem of translation/mapping; knowing whether ICD10's J12.2 |Parainfluenza virus pneumonia| is valid with respect to an extensible binding with 12188008 |Parainfluenza (disorder)| is hard
Lloyd McKenzie (Aug 13 2018 at 06:03):
Technically, yes. But you're going to make a lot of systems unhappy. (And it implies that the value set is broken for the purpose of use)
Lloyd McKenzie (Aug 13 2018 at 06:03):
(that was for your previous question)
Lloyd McKenzie (Aug 13 2018 at 06:04):
Expecting systems to call external terminology services for things like subsumes is well beyond what most systems are capable of now. And for a lot of logic, that'd be a peformance hit they couldn't manage.
Lloyd McKenzie (Aug 13 2018 at 06:04):
(because their logic wasn't designed to allow for that sort of possibility)
Michael Lawley (Aug 13 2018 at 06:05):
I'd expect them to use $compose in most cases, which allows bringing the actual test into the local db
Peter Jordan (Aug 13 2018 at 06:18):
If the developers of endpoint systems can't handle subsumption and don't want to use terminology services, one can hardly expect them to expand intensionally-defined SCT Value Sets. However, one would hope that if they are really serious about SCT, they would use closure tables and do some sound business analysis around using terminology servers rather than implementing that capability themselves.
Lloyd McKenzie (Aug 13 2018 at 06:22):
I don't expect them to expand them - I expect they'll have someone else who does it for them and they'll download a flat table every six months...
Peter Jordan (Aug 13 2018 at 06:24):
...and might that 'someone else' be a terminology services provider?
Lloyd McKenzie (Aug 13 2018 at 06:25):
Of some sort. But the key is that it's not a runtime process.
Michael Lawley (Aug 13 2018 at 06:30):
(Regarding the ADHA not using Extensible bindings, this is because validation will never fail. Although if the wording is tightened as is being proposed then it could fail due to the no-subsumption rule)
Peter Jordan (Aug 13 2018 at 06:37):
Interesting point @Lloyd McKenzie - the amount of calls made to external services by NZ GP and pharmacy systems is already very high, so their developers are well-versed in SOA optimisation strategies. We'll also view with interest the degree to which the ADHA is able to dictate the behaviour of endpoint systems in Australia.
Michael Lawley (Aug 13 2018 at 06:53):
ADHA dictates for anything that wants to connect to the MyHR. The interesting parts are what the flow-on effects are, and also where the AU base profiles go (i.e., how much of an influence they will have on Australian systems).
Grahame Grieve (Aug 13 2018 at 09:42):
I think that this discussion is kind of weird - extensible value sets and big snomed value sets don't really belong together, but that is the focus of the discussion.
Robert McClure (Aug 13 2018 at 14:15):
@Peter Jordan and others, as Lloyd keeps essentially pointing out, an Extensible binding should be used only when receiving systems are going to use the exchanged information in very specific ways and they will not be able to reliably determine what "meaning" a more specific code should be assigned. So in essence they are pushing that work onto the sending system. This binding should never be used in a situation that dictates user interface data collection.
Again, this is not about restricting the data collected at a point of care - EVER.
Robert McClure (Aug 13 2018 at 14:32):
@Rob Hausam I still like the text I suggested for the Extensible binding. I do not like the "can apply" phrase at all and think it is confusing. I think the text I supplied is understandable to non-terminology folks and is much more specific. I also am not in favor of using phrases like
or a particular hierarchical "level" of the concept
because "level" means nothing and has nothing to do with the issue at hand. When to plan on discussing this?
Rob Hausam (Aug 13 2018 at 14:32):
I want to talk more about this on the tracker issues call today and I have a use case scenario to discuss.
Rob Hausam (Aug 13 2018 at 14:42):
I want to adjust the wording more, too, and we’ll discuss on the call.
Peter Jordan (Aug 13 2018 at 19:47):
@Robert McClure - that's exactly the kind of explicit statement I was looking for, I owe you a beer!
Michael Lawley (Aug 13 2018 at 21:50):
+1 on the comment about level
Michael Lawley (Aug 13 2018 at 21:56):
Perhaps also @Robert McClure s statement about the intent of Extensible should be included somewhere. Many content-oriented terminology folk will not otherwise grasp this as they tend to be data-capture focussed
Rob Hausam (Aug 13 2018 at 23:27):
We worked on it further on the call today. And I'll add my +1 about level (even though I added it).
Grahame Grieve (Aug 13 2018 at 23:28):
I didn't understand this, if this is Rob's statement:
This binding should never be used in a situation that dictates user interface data collection
Grahame Grieve (Aug 13 2018 at 23:29):
because I think that's wrong. Setting a binding as extensible should dictate the users interface data collection. So you should only use it when it's a useful and important thing to do. (which is typically when you are not collecting a condition.code, for instance, and so we should stop talking about cases like that). A more useful care to talk about out is Observation.interpretationCode
Lloyd McKenzie (Aug 13 2018 at 23:47):
Whether it dictates data collection will vary. If you're complying with multiple value sets, the chances it'll influence data collection is low. If it's the only valueset in play and systems don't typically have legacy data/existing interfaces, then adoption of the extensible value set for user interface is more likely.
Rob Hausam (Aug 13 2018 at 23:50):
Observation.interpretation could be one of the best cases that we have where we've actually been using Extensible. And we could consider changing the examples to that or add more of them to include it (if we have at least one actually suitable interpretation code that isn't already in the value set - some have been proposed). Eventually I would like to get done with working on this, though. :)
Lloyd McKenzie (Aug 13 2018 at 23:56):
Done is always relative.. :)
Jay Lyle (Apr 22 2020 at 22:12):
Is "alternate concept" limited to the concept domain, or can we use a null value (unknown)?
Rob Hausam (Apr 22 2020 at 22:22):
Can you describe further what you're thinking of, Jay? I will say that when we say something like "alternate code" I think we're meaning something like a code from a different code system with the same meaning as the "primary" code (allowing for granularity differences). I don't think that a null flavor fits anywhere into that picture, but, again, maybe I don't know what you have in mind.
Jay Lyle (Apr 23 2020 at 00:36):
Device type. Systems don't have it. We could use "device" (root concept), or "unknown", but US core wants something. And the client won't take DAR.
Jay Lyle (Apr 24 2020 at 20:57):
So, @Rob Hausam unclear to me whether "unknown" should technically be a DAR or is permissible in 'extensible', or whether the root concept is part of the intensional set -- if "device" is-a "device"
Jay Lyle (Jun 05 2020 at 17:54):
Another case: religion.
Extensible binding, value of other or unknown: null flavor or DAR?
My prejudice is to use the nullFlavor and avoid the extension, though the US Core suggests you can put extend the values with DAR code as well. I also think the nullFlavor values are a better match.
image.png nullFlavor DAR
Other OTH unsupported
Unknown/no preference NI unknown
Asked but declined NAVU not-performed
Lloyd McKenzie (Jun 05 2020 at 18:01):
The recommendation is to include notions of other, unknown, etc. into value sets if the element is coded, NOT to use an etension
Jay Lyle (Jun 05 2020 at 18:08):
Thanks; absolutely. And it looks like the nullFlavor values, not the similar but less closely aligned DAR values.
Reece Adamson (Jul 07 2020 at 14:54):
I wasn't sure whether to post this here, #argonaut or #implementers , but I think it has more to do with the extensible binding than the content of the IG or a specific implementation.
I'm looking at a US Core AllergyIntolerance Resource which has an AllergyIntolerance.code of Allergy to Peanut 91935009 from SNOMED. This concept is not in the ValueSet which has an extensible binding on that element. However that ValueSet does include the Peanut (substance) 762952008 concept. From what I see, Allergy to Peanut 91935009 does not have a more general parent concept (or something higher in the is-a hierarchy) in the ValueSet that should be used instead. This ValueSet deals with substances and not reactions to substances.
My instincts tell me that the right thing to do here in this context would be to use Peanut (substance), to convey the same meaning consistently, but it really is a different concept (an allergy is a different thing than a substance) when taken independent of the encapsulating resource. Reading the spec docs on extensible bindings and thinking about it outside the context of the AllergyIntolerance Resource makes me think this is not an applicable concept that can be substituted.
TL;DR: For a ValueSet with an extensible binding, does the SNOMED concept Peanut (substance) 762952008 represent an "applicable concept" that shall be used for Allergy to Peanut 91935009 which is not in the ValueSet?
Thoughts on this and how to go about evaluating situations like this?
References and Examples
- Example Resource: allergy.json
- Relevant Profile: US Core AllergyIntolerance
- Relevant ValueSet: US Core Allergy Substance
- FHIR Specification Docs on Extensible Bindings
Lloyd McKenzie (Jul 07 2020 at 15:08):
Yeah, that's a bit of a mess. Strictly following the code system's subsumption hierarchy, the code is legal. Following the 'intent' of the code in context, it's not. Certainly having an example with 91935009 is confusing at best. @Brett Marquard @Eric Haas ?
Reece Adamson (Jul 07 2020 at 15:13):
Also, I should have been more clear here, but the example is one I created and not present in the IG. I was just trying to give an example of what I was talking about (i.e. if I get a resource like this, what do I do?).
Lloyd McKenzie (Jul 07 2020 at 15:17):
If your software is smart enough, add a coding for the SNOMED code for peanut when you store so that the instances you subsequently share are conformant, and perhaps spit back a warning. That's the most interoperable thing you can do. However, it's not an "easy" thing to do - extra coding and logical on your part plus ongoing terminology mapping work. Technically, you could allow the instance in "as is" and be conformant, though less interoperable. You could also reject the instance as non-conformant with the intent of the binding, though if it ever came to a courtroom, you'd be on shaky ground...
Reece Adamson (Jul 07 2020 at 15:24):
Thanks @Lloyd McKenzie for the insight!
I'm looking for the right thing to do according to the spec that would be expected or enforced as I'm coming at it from a standards/conformance perspective (not a pragmatic implementation perspective). So far it sounds like either code is applicable/allowable which is unfortunate from an interoperability perspective. I suppose the ValueSet definition would need to explicitly exclude these alternative codes in order to prevent this while maintaining the extensible binding.
Lloyd McKenzie (Jul 07 2020 at 15:28):
The value set excluding the codes wouldn't help given that the binding is extensible.
Lloyd McKenzie (Jul 07 2020 at 15:29):
The issue is the lack of ability to do "subsumption within context" - and I can't imagine how we could technically enable that on a general basis :(
Lloyd McKenzie (Jul 07 2020 at 15:30):
The spec could provide explicit language that "allergy" codes are not allowed - only substance codes. Though that creates challenges too...
Rob Hausam (Jul 07 2020 at 15:41):
Lloyd just said some of what I was getting ready to say, but I'll go ahead and say it anyway. The base AllergyIntolerance resource is explicitly intended to allow for the use of the "Allergy to x" codes (subtypes of 418038007 |Propensity to adverse reactions to substance (finding)|), as that's what some systems use to record allergies, rather than the substance codes. The binding in the base is only example, so there is complete flexibility there. And since the binding in the US Core profile is extensible, the "Allergy to x" codes are still allowed, even though they aren't included in the value set. The documentation doesn't seem to say anything explicit about that, but I suspect that even though technically those codes are allowed, their use wasn't intended to be "encouraged".
Rob Hausam (Jul 07 2020 at 15:46):
If in the profile it was determined that only codes from the SNOMED substance hierarchy and the other specified codes should be allowed, it should be possible to do that using a max binding.
Lloyd McKenzie (Jul 07 2020 at 15:57):
A max binding would mean that if you had an allergy to some weird thing outside the max value set, you couldn't send such allergies at all. I doubt you'd want to do that...
Lloyd McKenzie (Jul 07 2020 at 15:59):
If we wanted to do this computably, we'd need some sort of a new capability where in addition to asserting your base extensible value set you could also express a "prohibited" value set. I.e. "use these if one applies, if none of them apply then use any code you like, but you're never allowed to use codes from value set X." Not sure there'd be an appetite for that
Rob Hausam (Jul 07 2020 at 16:23):
Well, yes - that suggestion was essentially assuming that SNOMED will already have a code for any substance that anyone might be allergic to, which even though mostly true is almost certainly incorrect in the end. And yes, we don't have a mechanism for "prohibiting" codes as you described - and I agree that there might not be sufficient desire or need to ever have anything like that.
Robert McClure (Jul 07 2020 at 20:02):
@Rob Hausam Where in the US Core is it stated that the following is allowed?
The base AllergyIntolerance resource is explicitly intended to allow for the use of the "Allergy to x" codes (subtypes of 418038007 |Propensity to adverse reactions to substance (finding)|), as that's what some systems use to record allergies, rather than the substance codes.
I don't see that and am surprised that both you and @Lloyd McKenzie seem to fink it's ok to use SCT finding codes where it is very clear that a substance code is expected since the codes in the value set are all substance types. Same with the published examples and the text in the description. I suspect I'm missing something here
Lloyd McKenzie (Jul 07 2020 at 20:56):
I didn't say it was "fine". I do expect it to happen. Systems that actually use SNOMED internally will likely have the "allergy condition" code rather than the substance code - and their first impulse will send that code as the AllergyIntolerance.code. From a simple subsumption perspective, the allergy condition code wouldn't be a specialization of any of the codes in the value set, so technically it would meet the expectations of 'extensible'. Sending SNOMED codes from the wrong hierarchy isn't good practice, but it's pretty wide-spread (and in some cases necessary because there's no code from the 'appropriate' hierarchy, and sometimes not even an appropriate hierarchy). It's certainly against the spirit of both the definition of the attribute and the binding, but as I said, I'd hate to be in a courtroom saying that it's definitively not allowed.
Rob Hausam (Jul 07 2020 at 21:17):
@Robert McClure What I was describing is in the base AllergyIntolerance resource and value set. Part of that value set definition is Include codes from http://snomed.info/sct where concept is-a 418038007 (Propensity to adverse reactions to substance). And I agree with Lloyd about what is at least technically allowed by the extensible binding to the value set in US Core.
Reece Adamson (Jul 07 2020 at 21:19):
@Robert McClure The closest language I could find that allows for AllergyIntolerance.code to be either a substance or adverse reaction to a substance is in the base FHIR definition of AllergyIntolerance.code. I don't see any US Core specific language about allowing either substance or allergy codes.
This may be a code for a substance or pharmaceutical product that is considered to be responsible for the adverse reaction risk (e.g., "Latex"), an allergy or intolerance condition (e.g., "Latex allergy"), or a negated/excluded code for a specific substance or class (e.g., "No latex allergy") or a general or categorical negated statement (e.g., "No known allergy", "No known drug allergies").
There are probably good reasons for this language, but it's concerning to see diversity in how the same allergy is reported.
Reece Adamson (Jul 07 2020 at 21:31):
Interestingly as I look closer at the specific ValueSet in question I see some text about the inclusion and exclusion criteria. Note this is an extensional ValueSet which does not contain any ValueSet.compose.exclude elements.
Inclusion Criteria: specific or general substances to which a patient may be exposed and which may be suspected of causing an adverse reaction; assertions refuting these suspicions. This includes: 1. Common dietary substances for allergy and intolerance documentation (SNOMEDCT) 2. Common drug classes for allergy and intolerance documentation (SNOMEDCT) 3. Common drug substances for allergy and intolerance documentation (RXNORM) 4. Common environmental substances for allergy and intolerance documentation (SNOMEDCT) 5. Common refutations and null values for substance causes for allergy and intolerance documentation (SNOMEDCT)
Exclusion Criteria: actual conditions caused by exposure (reactions, allergies)
It seems like this language is targeting this scenario and prohibit codes which are about the allergy rather than the substance. I don't think this can be taken as a requirement though as the ValueSet.description "specifies the span of meanings for concepts to be included" which in this case is indicated the ValueSet only includes substance codes and not conditions.
Another potentially relevant clue at least.
Robert McClure (Jul 07 2020 at 21:36):
Yes, I see that the base AllergyIntolerance resource does indeed allow either a substance or a finding in the code element. @Reece Adamson This kind of diversity in approach is a hallmark of FHIR given the requirement at the base-level to support the existing implemented melange of approaches. IMHO that means it's up to those who want real interoperability to define an IG that removes unhelpful variation. I think USCore has tried to do that and while technically Lloyd and Rob are correct that with an extensible binding, no Max constriction, and the base example binding including finding-type concepts; you can argue that it's fine to throw findings back into the mix.
I'd rather we see an implementation add a concept map that can be used to map the implied substance in the finding to the actual substance. For at least some SCT concepts the conceptual model makes that easy.
Reece Adamson (Jul 07 2020 at 21:42):
Thanks @Robert McClure that makes sense and I appreciate you taking the time to help explain it to me!
Rob Hausam (Jul 07 2020 at 22:02):
The reason that the "Propensity to adverse reactions to substance" codes are there in the base resource is that those codes do exist in SNOMED CT and some systems actually do use them to record allergies. I think that possibly is not being done by any systems that are operating strictly in the US, but I don't know that for certain. I think that USCDI/ISA seems to be more specific than the US Core value set, but I also just noticed that ISA has part of this wrong, as it says:
Representing Adverse Reactions/Intolerances
- Propensity to adverse reactions to drug (disorder) (SNOMED CT 419511003) is parent to:
- Drug Allergy (disorder) (SNOMED CT 416098002) and child terms/codes
It's using these "Propensity to adverse reactions" (allergy to 'x') codes for representing the "Adverse Reactions/Intolerances" - but it's misunderstanding their meaning, as, of course, they actually represent the allergy condition.
Michael Lawley (Jul 09 2020 at 05:06):
FWIW, any decent terminology server should be able to follow the causitive agent relationship on an "allergy finding" to find the "substance" in question. This can be done directly with $lookup or slightly indirectly using $expand and an (implicit) ValueSet defined using ECL. No need to jump through hoops to define and build a ConceptMap.
Note, you won't always end up at a specific substance -- when recording an allergy to a product, for example, it is unknown which component(s) of the product are the problematic substances.
Grahame Grieve (Jul 09 2020 at 11:28):
doesn't that imply the thing exists
Last updated: Apr 12 2022 at 19:14 UTC
