Stream: terminology
Topic: ICD-10 Hierarchy
Mark Kramer (Oct 12 2020 at 16:56):
If a value set contains a three-character ICD-10 code, are the four, five, or six character expansions under that heading implicitly included in the value set? For example, if a value set contains D53 Other nutritional anemias, would D53.0 Protein deficiency anemia be valid? If not, is there a filter (such as is-a) that would do that?
Lloyd McKenzie (Oct 12 2020 at 17:40):
If you want to include specializations, the value set needs to specifically be defined using is-a. I believe is-a is recognized for ICD-10
Mark Kramer (Oct 12 2020 at 19:19):
@Lloyd McKenzie That's what I hope, it would save a ton of work, but there is information to the contrary here: http://www.hl7.org/fhir/icd.html#4.3.11.5. Am I missing something?
Mark Kramer (Oct 12 2020 at 19:20):
@Rob Hausam ?
Rob Hausam (Oct 12 2020 at 19:27):
Yes, that certainly implies that we haven't defined this for ICD-10 (and variants). Some servers may already support the "concept" filter with 'is-a' (tx.fhir.org may, but I would need to check). I do think it makes sense to have it for ICD-(X). @Mark Kramer Do you want to submit a tracker?
Mark Kramer (Oct 12 2020 at 20:07):
I think that feature would be extremely useful for specifying value sets, indeed. If you can do a tracker and check on the publication server, doubly so.
Grahame Grieve (Oct 12 2020 at 20:51):
tx.fhir.org does not.
Grahame Grieve (Oct 12 2020 at 20:52):
I will do it if we agree that we should. And seems to me we should, with heirarchy = classification
Grahame Grieve (Oct 12 2020 at 20:52):
one reason I don't yet is because we haven't had a full code system yet
Michael Lawley (Oct 12 2020 at 21:01):
I always interpreted that as meaning no additional ICD specific filters, but anything with relevant hierarchyMeaning should also have concept is a implicitly included. Certainly this is how Ontoserver works
Rob Hausam (Oct 12 2020 at 21:04):
@Grahame Grieve Yes, it wouldn't have been particularly useful without the full code system - but that should be there soon (and I know I've been saying that - but it's nearly there).
Grahame Grieve (Oct 12 2020 at 21:30):
I agree with @Michael Lawley
Robert McClure (Oct 12 2020 at 22:02):
@Mark Kramer I assume you understand this but for the sake of clarity for others finding this thread, you said something that is technically not true:
If a value set contains a three-character ICD-10 code, are the four, five, or six character expansions under that heading implicitly included in the value set
^^that is never true. (waiting for arrows...) What is true is if the CLD compose uses the is-a filter op and the value is a code that has descendants, then a terminology server that has the entire code system (content =complete) and either assumes the hierarchy represents is-a (as in Ontoserver,) or once we clarify for others that the hierarchy is in fact an is-a, should expand and produce the set of concepts you wanted.
Grahame Grieve (Oct 12 2020 at 22:03):
heirarchy is classified-with not is-a. But the filter in should work anyway
Robert McClure (Oct 12 2020 at 22:07):
@Grahame Grieve I agree that is the correct relation but it's not in the required binding FilterOperator value set (at least not in the current version.) In makes no sense.
Grahame Grieve (Oct 12 2020 at 22:07):
umm.
Grahame Grieve (Oct 12 2020 at 22:07):
guess we'll have to add something. I overlooked that one
Robert McClure (Oct 12 2020 at 22:09):
Make a JIRA ticket ;-)
Chris Moesel (Oct 12 2020 at 22:25):
I'm about to show some of my terminology ignorance here, but... @Grahame Grieve said:
heirarchy is
classified-withnotis-a
But SNOMED-CT uses is-a to represent descendantOrSelfOf [concept] (link), which seems like hierarchy to me. So... what is the difference?
Grahame Grieve (Oct 12 2020 at 22:25):
in snomed, the heirarchy is based on is-a relationship, so heirarchy and is-a are the same thing
Grahame Grieve (Oct 12 2020 at 22:26):
but icd-10 is not
Chris Moesel (Oct 12 2020 at 22:27):
Ah. OK. So it differs because although both systems use hierarchy, the meaning that the hierarchy implies is different in SNOMED than ICD-10. Got it. (Unless I don't, in which case I expect someone will tell me ;-)).
Robert McClure (Oct 12 2020 at 22:42):
@Chris Moesel Classification hierarchies only allow a single parent and a parent is used to collect things that vary but share some common context. For ICD it's tied to a melange of resource use, pathophysiology, and death predilection.
Lin Zhang (Oct 12 2020 at 23:39):
And all the children of the same parent are disjoint/mutually exclusive with each other.
Lin Zhang (Oct 12 2020 at 23:44):
@Grahame Grieve What do you mean by "...we haven't had a full code system yet"? I think you already have the official distribution (zip file) from WHO's ICD site.
Grahame Grieve (Oct 13 2020 at 00:28):
oh. I was thinking about the US distribution
Lin Zhang (Oct 13 2020 at 00:29):
Right now, we are working on how to import WHO ICD-10 and its national/regional variants. And I'm wondering how to express the parent-children relationships (maybe also including other ones such as includes/excludes). The Bioontology version uses an is-a for parent-child relationships, IIRC.
Lin Zhang (Oct 13 2020 at 00:29):
Got it, thanks.
Grahame Grieve (Oct 13 2020 at 00:31):
we probably haven't clarified this enough - the code system for ICD-10 has a heirachy, with codes and displays, and the heirarchyMeaning is classified-with. so through out the fhir framework, ICD codes have parents and children, and descendents, but they do not have is-a relationships
Lin Zhang (Oct 13 2020 at 00:31):
Yes, agree.
Lin Zhang (Oct 13 2020 at 00:35):
Maybe mutually-exclusiveness is a major feature the "classified-with" has , which is ditinguish it from "is-a".
Grahame Grieve (Oct 13 2020 at 00:50):
well, the narrow definition of is-a is that A is-a B if all the properties of A are also properties of B (though 'meta-properties' like authoring date don't count).
In classifications like ICD-10, this is not a requirement, though it is generally and mostly true anyway.
So as you say, true classifications are mono-heirarchies that you treat exclusively, and also, they are not always based on is-a
Lin Zhang (Oct 13 2020 at 01:07):
As Apelon's DTS does, a useful mitigation/solution might be separating thesaurus from DL-based ontology to allow for loosely defined parent-child relationships.
Michael Lawley (Oct 13 2020 at 01:32):
guess we'll have to add something. I overlooked that one
I hope you mean "extra words that indicate the relevant FilterOperators about about hierarchy traversal, not about hierarchyMeaning" rather than adding a new FilterOperator :scream:
Michael Lawley (Oct 13 2020 at 01:35):
But the filter
inshould work anyway
@Grahame Grieve how is the filter in relevant to these hierarchy questions?
Grahame Grieve (Oct 13 2020 at 02:25):
well, the problem with what you want - which is what I would want to - is that the current filters are defined in terms of is-a. And are normative. So I didn't suggest that (I didn't suggest any particular solution)
Grahame Grieve (Oct 13 2020 at 02:25):
we already talked about 'in' with LOINC
Rob Hausam (Oct 13 2020 at 06:02):
In practical terms, I'm not sure that we need to treat the classifications differently than more semantically rich and precise terminologies like SNOMED CT - the hierarchies (whether "classified-with" or "is-a") still will (or at least can) behave in the same way in regard to terminology operations. If we (any of us) think that's not the case, we should look at some specific examples.
Lin Zhang (Oct 13 2020 at 06:40):
The following site would return a so-called json for the ICD-10 code that user selects:
https://1up.health/health-data/icd10
But it looks wierd.
Mark Kramer (Oct 13 2020 at 12:57):
I concur with the idea of “in” or “classified-with” filter. The actual example we can use is comorbidity index, like Charlson or Elixhauser. Each comorbidity category is defined by a set of codes, frequently with elements like C45.x meaning everything “in” the C45 category.
See https://cran.r-project.org/web/packages/comorbidity/vignettes/comorbidityscores.html
Rob Hausam (Oct 13 2020 at 14:23):
It seems to me that what we should do is expand (or clarify) the meaning of the 'is-a' filter operator (and likewise also 'descendent-of' and 'generalizes') so that it is clear that it applies to and may be used with any of the transitive hierarchy meanings (e.g. 'is-a', 'classified-with', 'part-of').
Robert McClure (Oct 13 2020 at 14:46):
@Mark Kramer @Grahame Grieve No matter how you want to craft an explanation of how In can work for LOINC, the use of In for parsing pieces of the ICD code structure should be absolutely out of bounds. Otherwise we'll be telling people to parse code text structure using In anywhere they want to. Please, let's not do this. We have a structure for the concepts USE IT.
Mark Kramer (Oct 13 2020 at 18:57):
"in" is a set-membership concept. I don't know where parsing comes into play. But I agree it is not what we want for ICD categories.
Rob Hausam (Oct 13 2020 at 20:58):
Agree.
Grahame Grieve (Oct 13 2020 at 20:59):
is expand (or clarify) the meaning of the 'is-a' filter operator (and likewise also 'descendent-of' and 'generalizes') so that it is clear that it applies to and may be used with any of the transitive hierarchy meanings (e.g. 'is-a', 'classified-with', 'part-of'
I'd be happy with this in principle but I'm concerned about whether this is procedurally possible
Rob Hausam (Oct 13 2020 at 21:28):
Can you expand on what you think "is (not) procedurally possible"?
Grahame Grieve (Oct 13 2020 at 21:51):
changing the definition of is-a like that
Michael Lawley (Oct 13 2020 at 21:59):
Our approach is that hierarchy is represented with parent/child edges (properties) and that is-a and friends are about transitive traversal of these edges. With this lens, the interpretation is purely structural. The hierarchyMeaning field of the CodeSystem then tells you what the semantics of the structure are, but this is distinct from the filter operators.
The alternative is a separate set of filter operators for each hierarchyMeaning and that doesn't help anyone AFAICT.
Grahame Grieve (Oct 13 2020 at 22:03):
in principle I agree with that but that's not the current definitions, and wishful thinking won't make procedural issues go away
Rob Hausam (Oct 13 2020 at 22:07):
Yes, I agree with what Michael just said. And before I saw that I had written this:
As I mentioned before, there are two different 'is-a' concepts here - they have the same description (obviously), and there's certainly a relationship, but the definitions and contexts of use are different. If we interpret the 'is-a' filter operator "strictly" and decide that means that we need to add another concept for the 'classified-with' filter, then I think that we will also have to do the same for 'descendent-of' and 'generalizes', because all three of them are described as being "by subsumption" and they share the "Includes all concept ids that have a transitive is-a relationship" either with/from "the concept Id provided as the value" as the first (and primary) part of their definitions. It doesn't seem to me like that is something that is either actually necessary or desirable to do.
And Michael's description of this as "purely structural" is exactly what I am getting at.
Grahame Grieve (Oct 13 2020 at 22:11):
and I'd like to agree with that. My question isn't about desire, it's procedural
Michael Lawley (Oct 13 2020 at 22:15):
Is this the is-a definition you mean?
The definition of is-a is that all the properties of the value are true for the specified property of the code, which means that a code has an is-a relationship with itself.
Grahame Grieve (Oct 13 2020 at 22:15):
yes
Rob Hausam (Oct 13 2020 at 22:15):
I think it's a clarification that the definitions of the filter concepts are structural based on transitive traversal of the edges , as Michael said - and the rest is essentially descriptive in regard to how it applies in the case of the "is-a" based hierarchy, but that it is applicable to the other hierarchies in the same way based on their structure. It should break nothing that currently exists and is being done.
Michael Lawley (Oct 13 2020 at 22:16):
Because that is contingent on which properties you consider to be in scooe
Michael Lawley (Oct 13 2020 at 22:16):
Scope
Michael Lawley (Oct 13 2020 at 22:18):
It doesn't hold, in the SNOMED case, for non defining props or things like effectiveTime, moduleId, primitive, etc
Grahame Grieve (Oct 13 2020 at 22:19):
It should break nothing that currently exists and is being done.
That's where my problem is. redefining the meaning will not exclude codes that are being included, but it may include codes that are presently being excluded.
For instance, if I have a code system that has both is-a relationships, as well as part-of (and we do have them), what does is-a mean? It only includes part-of if they are the heirarchy?
Michael Lawley (Oct 13 2020 at 22:19):
Procedurally we can clarify / fix this with appropriate consultation?
Michael Lawley (Oct 13 2020 at 22:20):
In that case I would expect hierarchyMeaning to be is-a and part of to be irrelevant
Michael Lawley (Oct 13 2020 at 22:21):
There's no mechanism for two hierarchies
Grahame Grieve (Oct 13 2020 at 22:21):
that's according to the current definition. but if we redefine it as requested, then we make a mess of that case
Michael Lawley (Oct 13 2020 at 22:21):
I don't believe so. There's still only one hierarchy
Grahame Grieve (Oct 13 2020 at 22:22):
really? which one?
Michael Lawley (Oct 13 2020 at 22:22):
The one that the CodeSystem chooses (and nominates with hierarchyMeaning).
Michael Lawley (Oct 13 2020 at 22:23):
It'll be a mess if partOf is chosen, but I would argue that would be no different today
Grahame Grieve (Oct 13 2020 at 22:23):
because right now, you could choose either property on which to base the heirarchy but the definition of is-a is not linked up to the heirarchy, but the is-a property. We're proposing changing that, and I think that's problematic, as much as I think it would be good if we can
Michael Lawley (Oct 13 2020 at 22:25):
Is there a CodeSystem with is-a semantics that uses hierarchy to represent part-of?
Grahame Grieve (Oct 13 2020 at 22:26):
well, no. but there should be. The definition of https://terminology.hl7.org/CodeSystem-v3-AddressPartType.html is incorrect - the heirarchy meaning should be part-of, not is-a, but the heirarchy is correct.
Michael Lawley (Oct 13 2020 at 22:30):
DAL and SAL are part-of AL not is-a AL? The hierarchy, such as it is, looks fine to me, as do the partOf properties.
Grahame Grieve (Oct 13 2020 at 22:31):
yes. I personally think that's not necessary, but that's how it's defined, and the MIF import has missed that
Grahame Grieve (Oct 13 2020 at 22:31):
(@Ted Klein)
Rob Hausam (Oct 13 2020 at 22:34):
Basically, where it says "transitive is-a relationship" in the filter-operator code system concept definitions, that would become "transitive hierarchical relationship" (or at least that's how it could be interpreted) and then we could also clarify that the hierarchy being referred to is the one that is declared by CodeSystem.hierarchyMeaning.
Michael Lawley (Oct 13 2020 at 22:34):
Or are you saying that the CodeSystem would be "better" if part-of had been represented in the hierarchy rather than as a property?
Grahame Grieve (Oct 13 2020 at 22:35):
that code system is representing part-of in the heirarchy, it just doesn't declare it so
Michael Lawley (Oct 13 2020 at 22:40):
When I look at the HTML rendering and the JSON, the only hierarchy I see is AL as a parent of DAL and SAL. I also see that BNR has a property partOf to SAL. So I don't understand what you mean?
Grahame Grieve (Oct 13 2020 at 22:49):
no apparently I didn't read it carefully enough.
Grahame Grieve (Oct 13 2020 at 22:50):
but if we had chosen to reflect the part-of relationship in the heirarchy then the redefinition would be a problem.
Grahame Grieve (Oct 13 2020 at 22:51):
if we can be confident that there are no code systems out there with is-a relationships and that have a heirarchy that isn't based on is-a, then redefinition would work. I'm still not sure what the procedural basis for it is
Michael Lawley (Oct 14 2020 at 00:16):
I see the following relevant pieces of text (https://www.hl7.org/fhir/versions.html#f-compat):
Descriptive information about a resource - short labels, definitions, usage notes, aliases, examples, rationale, mappings, etc. may be updated or revised to provide additional clarity or guidance, but not in such a manner as to invalidate a reasonable interpretation of the previously documented use of an element. (This does not preclude fixing obvious errors.)
and
Definitions and display values for codes may change, but only in a manner that would not change the reasonable interpretation of data captured using the previous definitions or names.
Also:
NOTE: In rare circumstances, HL7 may approve changes that technically break one of the above rules in situations where there is a high level of confidence that the change will not impact existing implementers. Such deviations from these declared rules will involve broad notification, extensive community consultation and reviews by multiple levels of HL7 governance processes
So, if we are comfortable of a consensus that the proposed change doesn't invalidate reasonable interpretations of the current wording, then we should be ok?
Grahame Grieve (Oct 14 2020 at 00:23):
I think we are it the final of the 3 spaces, yes
Last updated: Apr 12 2022 at 19:14 UTC
