Stream: terminology
Topic: Code System filters
Grahame Grieve (Jul 12 2016 at 19:46):
@Rob, with regard to GF#10221, I made a mistake in the expression of this, which caused you to create the wrong disposition in the block vote, and I didn't pick up on it
Grahame Grieve (Jul 12 2016 at 19:46):
@Rob Hausam. The description should have read:
Grahame Grieve (Jul 12 2016 at 19:46):
There's a set of filters that are inherent in the structure of the *Code system resource* - for example, is_a. Do these need to be explicitly documented in a code system resource, or are they implied? (if stated explicitly in the spec, which they aren't, so this should be addressed)
Grahame Grieve (Jul 12 2016 at 19:47):
so the question was: must you explicitly define the filters in every code system, or can we define them once in the spec
Grahame Grieve (Jul 12 2016 at 19:51):
the filters are:
concept is-a / is-not-a / regex / in / not-in
Grahame Grieve (Jul 12 2016 at 19:51):
e,g. any code system defined using the code system resource, these apply
Grahame Grieve (Jul 12 2016 at 19:51):
well, that is, *if* the heirarchy is based on subsumption. which we don't let you say....
Rob Hausam (Jul 12 2016 at 20:16):
that makes sense - so presumably, then, we should open this up again on the call next week?
Grahame Grieve (Jul 12 2016 at 20:21):
well, I need to commit before then - so if we can decide on something here with enough consensus....?
Grahame Grieve (Jul 12 2016 at 20:21):
though maybe, given the problem of heirarchy, we can't?
Grahame Grieve (Jul 12 2016 at 23:02):
getting back to this - the problem is, if we say that you define the filters above explicitly in every code system, that becomes a proxy marker for 'meaning of heirarchy'. if we define it implicitly in the spec, we need to define the 'meaning of heirarchy' element explicitly.
Grahame Grieve (Jul 12 2016 at 23:04):
the first sits badly with me with regard to outcomes. The second sits badly with me with regard to process. I guess I reopen this task, send it back to committee, and it won't make it into the Spet ballot
Michael Lawley (Jul 13 2016 at 01:31):
Regarding the filter 'regex' - is the a standard set of properties that this applies to, or is it all properties of the CodeSystem or is it CodeSystem-specific?
Rob Hausam (Jul 13 2016 at 01:37):
there's no reason that we can't do an evote, if needed (and it appears to be in this case)
we haven't done a lot of that in Vocab, but that doesn't mean that we can't or shouldn't
I think we should try to get it resolved and in for Sept.
Grahame Grieve (Jul 13 2016 at 01:39):
regex specifically refers to the code, and no other property
Grahame Grieve (Jul 13 2016 at 01:40):
let's go for an eVote then. but what to propose? we hvave 2 decisions - about ExpansionProfile, and this one
Erich Schulz (Jul 13 2016 at 01:41):
ewww... regex vs code? that's seriously skanky
Grahame Grieve (Jul 13 2016 at 01:42):
it's really useful in classifications that have the structure explicit in the code. otherwise, not so useful
Erich Schulz (Jul 13 2016 at 01:43):
very steam-punk
Erich Schulz (Jul 13 2016 at 01:45):
I've been lured down the path of embedding knowledge into cryptic little regular strings... it rapidly fails-to-scale tho... but meh
Grahame Grieve (Jul 13 2016 at 01:45):
ICD-X...
Erich Schulz (Jul 13 2016 at 01:46):
case in point :-)
Grahame Grieve (Jul 13 2016 at 01:46):
you'll find nearly unanimous agree here that's a Very Bad Idea. but that doesn't mean that other people don't do it
Erich Schulz (Jul 13 2016 at 01:47):
everyone thinks oh I'll just /^E09.*/ and i'll be fine...
Erich Schulz (Jul 13 2016 at 01:47):
like the capitals :-) VBI... mind you I can see me doing it...
Grahame Grieve (Jul 13 2016 at 01:47):
so, I still very much prefer to add an element to define that the meaning of the code system is heirarchical, and then define implicit filters as part of the code system resource.
Grahame Grieve (Jul 13 2016 at 01:48):
can we get an eVote together on that? One that even @Robert McClure might support?
Rob Hausam (Jul 13 2016 at 01:51):
still not sure why you need an element to tell you if it's hierarchical
if it's a flat list, it's not
and if it has is-a (or part-of) relationships, it is
Rob Hausam (Jul 13 2016 at 01:52):
or nesting of any kind
Grahame Grieve (Jul 13 2016 at 01:52):
well - that's exactly it: if it has heirarchy, it has is-a, or part-of, relationships (though we strictly identified a 3rd, in the classification space)
Grahame Grieve (Jul 13 2016 at 01:53):
where as all the operations are specific: is-a. not part-of or classified-with
Rob Hausam (Jul 13 2016 at 01:53):
right
Grahame Grieve (Jul 13 2016 at 01:54):
so not providing that information specifically leaves the terminology service guessing
Grahame Grieve (Jul 13 2016 at 01:55):
if we add the element - which vocab turned down before - then we can say that the is-a based operations can be used on the value set *if* the code system says it's subsumption based
Grahame Grieve (Jul 13 2016 at 01:56):
I think that the vocab call got distracted on the edge cases where a single terminology has more than one kind of relationship isn it's heirarchy. In which case, a/ it's too complex for CodeSystem anyway and b/ if you really want to use code system, don't use the heirarchy
Rob Hausam (Jul 13 2016 at 01:58):
that's probably right
I guess it's not unreasonable to ask for the CodeSystem resource to declare the capabilities of the code system for use with the is-a operation
Grahame Grieve (Jul 13 2016 at 02:00):
well put
Erich Schulz (Jul 13 2016 at 02:04):
curious for an example of distinction between is-a and classified-with...
also wondering why a terminology service would ever be left guessing because I would have assumed that a terminology service grokked the terminologies it was peddling (sorry more noob questions)
Grahame Grieve (Jul 13 2016 at 02:07):
the discussion refers to code systems made available to the terminology through the code system resource.
Grahame Grieve (Jul 13 2016 at 02:08):
and we are dealing with how it will grok them. because right now, for instance, you would not know which of the v3 code systems has a heiarachy that is not subsumption based (there's a very few)
Grahame Grieve (Jul 13 2016 at 02:09):
technically, a good classification will ensure that the heirarchy is strictly subsumption based. But a close examiniation of some of them demonstrates that there's no intensional or extensional definition provided (or even possible) some classifications that includes all the sub-categories
Erich Schulz (Jul 13 2016 at 02:13):
so this is effectively about rubbish classifications saying "I'm rubbish"?
Grahame Grieve (Jul 13 2016 at 02:13):
that's one way to phrase it
Erich Schulz (Jul 13 2016 at 02:14):
trouble usually is that one person's rubbish is another's treasure...
Erich Schulz (Jul 13 2016 at 02:16):
or "it seemed like treasure when we put it together, but now we've sobered up... not so much"
Erich Schulz (Jul 13 2016 at 02:17):
(ie just wondering how much order can be extracted from woolly judgement calls about regularity lost in translation)
Erich Schulz (Jul 13 2016 at 02:18):
because I'm finding it difficult to imagine people deliberately constructing a hierarchy that at the time didn't feel like a classification
Grahame Grieve (Jul 13 2016 at 02:18):
off-topic, with regard to seemed like treasure when drunk: http://m.nzherald.co.nz/lifestyle/news/article.cfm?c_id=6&objectid=11673006
Erich Schulz (Jul 13 2016 at 02:18):
sorry naive rambling as usual
Erich Schulz (Jul 13 2016 at 02:21):
but i may take my spouse to see Tarzan...
Michael Lawley (Jul 13 2016 at 03:12):
It's confusing: "The specified property of the code..." which doesn't sound like the code itself. Also, which flavour of regex?
Grahame Grieve (Jul 13 2016 at 03:21):
the filter specifies what it applies to. but It doesn'tactually say right now, and that's what I want to fix
Michael Lawley (Jul 13 2016 at 03:26):
simplistically, is-a will always lead to a need for poly-hierarchy (DAG); any statistical classification will be a mono-hierarchy (tree), so you get missing is-a relationships. Further, when you have NEC and NOS codes, these play havoc with a strict is-a interpretation
Erich Schulz (Jul 13 2016 at 05:19):
@Michael Lawley is that in reference to my question?
Michael Lawley (Jul 13 2016 at 06:09):
@Erich Schulz yes :-) The lack of reply threading is pretty frustrating :-(
Erich Schulz (Jul 13 2016 at 06:46):
ok cool - I guess I have quibble with the classified-with as it misses the point that with statistical classification trees and DAGs the issue isn't with the relationships (I'd argue both are really is-a-subclass-oflinks) the issue really is that the codes themselves have occult meaning partially defined by the relationships (and the NEC rules etc)
Grahame Grieve (Jul 13 2016 at 07:09):
well, that's what I was atttempting to get at: this code system is actually a classification where the heirarchical relationships is authoritative for classification, but you should not attempt to interpret it as strictly subsumptive.
Erich Schulz (Jul 13 2016 at 07:21):
I guess I'm saying the problem start before you even try to do subsumption, expansion...
eg http://apps.who.int/classifications/icd10/browse/2016/en#/X
Grahame Grieve (Jul 13 2016 at 07:22):
not sure what you mean the problem is
Erich Schulz (Jul 13 2016 at 07:23):
the problem is that the code itself has occult meaning...
ie ^J.*/ does not equal "Diseases of the respiratory system"
Erich Schulz (Jul 13 2016 at 07:23):
it means "*some* Diseases of the respiratory system"
Grahame Grieve (Jul 13 2016 at 07:24):
right
Erich Schulz (Jul 13 2016 at 07:24):
i'm not sure its a big deal - its just that the relationships that are stated are actually fine...
its just they are incomplete
Erich Schulz (Jul 13 2016 at 07:25):
I maybe splitting hairs
Robert McClure (Jul 15 2016 at 01:06):
Folks, trying to follow this so you can get to an eVote if that is desired. To some degree the words are tripping us up so let me say what my words are: Subsumption means the hierarchy is transitive along whatever the the hierarchical relationship is. I tend to think of transitivity as a state and subsumption as the action based on that state but they essentially say the same thing - BUT you must know what relation is defined as transitive before you use the hierarchy. I know Graham this is why you want the hierarchy type clearly defined and I agree it's useful.
There are two transitive relations (that I know of off the top of my head but there are likely others in specialized systems - I think genetics has some odd ones.) Those are: IS-A then the child "IS-A" kind of whatever the parent seems to be. The other is "Part of", (whole-part or meronomic) then the child is part of the parent. It is my understanding that such a hierarchy also supports what we'd call "Subsumption".
Another hierarchy is "a classification hierarchy" which is a slippery phrase because that word is used in DL when one uses logic to create an inferred hierarchy al la SCT. But when we use the word "classification hierarchy" we usually mean what you all have been calling "a statistical classification" such as ICD. These are by definition a single hierarchy that is a closed world - everything MUST fit. In this case the relations are by definition NOT Transitive (in logic) but to a human, some of them may seem to be so.
Finaly we have the "What ever I want" hierarchy (parent-child) that is essentially "grouped-by". This is not transitive and does not support subsumption.
I sense from this that you want to be able to know when using transitive closures makes sense in a value set definition, or some other "subsumption-based" queries and I absolutely agree with this. Graham, If this is exactly the issue that was voted down by vocab before then we must have been talking past each other. I'd vote to add this as an element of the code system resource. It would be my preference to make this very explicit. In DTS for example all concepts are related to each other via named relationships and one of those is defined as the hierarchial relation AND it is flagged as transitive or not. The meaning of the transivity is reflected in the meaning of the relation (e.g: IS-A versus part-of). We could cover all the bases by making a default hierarchy relation (as was discussed in the other thread) - grouped-by. If the hierarchy is more specific, IS-A, Part-Of, or Classification-of should also be available to use. You can then flag it as transitive (this should be limited to the first two choices. )
Would that (or something like it) be ok?
Grahame Grieve (Jul 15 2016 at 01:15):
ok thanks. sounds like progress. But surely, given the definitions of is-a and part-of, those relationships must be transitive?
Grahame Grieve (Jul 15 2016 at 01:16):
and given the definitions of 'grouped-by' and 'classified with' - they might be transitive, but the who the hell cares?
Grahame Grieve (Jul 15 2016 at 01:18):
so I'd argue that we should add an element to classify the heirarchy that has 1..1 cardinality, and a value of grouped-by | classified-with | is-a | part-of, and where we say that is-a and part-of are implicitly transitive by their definition, and any transitivity associated with the other 2 can only be established by carefully considering the definitions (likely to be different through the heirarchy, and probably mostly ambiguous)
Robert McClure (Jul 15 2016 at 16:47):
@Grahame Grieve I agree with that approach pending your thoughts on these two questions:
1) Understanding that "grouped-by" is a general use case and that "careful consideration" could result in determining that the hierarchy is transitive (the code system could state that explictly), in that situation could a FHIR implementer still execute the transitive closure operations on that code system?
2) What do we do with a code system that has explicit relations between the code that are used to form the hierarchy and they are not "grouped-by" - they use a different named relationship. Is there a reason this process would care? We'd want to be able to capture that actual relationship in the representation of the code system even though in this case we are calling it "grouped-by".
Rob Hausam (Jul 15 2016 at 17:26):
@Robert McClure Good questions. If we can't come up with notions of a need for performing $closure and $subsumes operations on hierarchical code systems that are not based on either is-a or part-of, then Grahame's approach may work just fine.
Grahame Grieve (Jul 15 2016 at 20:26):
$closure is specificaiily defined as subsumption only. So the question isn't relevant. If you think we need to extend closure (and $subsumes) to non- is-a heirarchies, that would be a different discussion.
Grahame Grieve (Jul 15 2016 at 20:27):
as I understood your project, 'grouped-by' was not a 'name', it's a classification. People could call their relationship whatever they wanted (could use an extension if they wanted to)
Rob Hausam (Jul 16 2016 at 02:11):
Transitive closure in general is based on transitivity, and isn't dependent on strict subsumption - it can be on any transitive binary relation. If we're defining it to be for subsumption only, we can certainly do that, but we don't really have to. So that's where the question could become relevant.
Grahame Grieve (Jul 16 2016 at 05:31):
well, we are defining it for subsumption only. is that a problem?
Robert McClure (Jul 17 2016 at 19:28):
You know, I now realize we've not been quite correct in our use of words, myself included. I've been using the word "transitive" to mean not only "related to", which is the actual formal logic definition, but also to mean "inherits" and I'm pretty sure that is not formally true. A transitive closure operation is used to find all entites that "are related" (given a defined or default relation) to the root of the closure via a graph closure. This means that _every_ hierarchy should support a graph closure operation, i.e.: a transitive closure. As I try to piece this to gether in my head I suspect we could/should be using the word "Transitive" as another way of naming the hierarchical relation - i.e.: it is "the transitive" relation. The idea that via that (or any other) relation the related concept _inherits_ the attributes of the source concept is a separate notion of _inheritance_. Based on this "Subsumption" where A subsumes B is a state where the relationship between A and B is both transitive (creates a hierarchy) and inheritance.
What this means for FHIR is that ALL hierarchy relations are transitive and the closure operation should work on all of them. Even if you don’t agree with the word definitions I’m just stated (and I’m struggling to find good references for this) I’m confident that we need to support closure on any hierarchy relation and honestly, any relation at all. But keep in mind closure ALWAYS must have a relation it is following, and yes, it’s possible to get a cycle so your code needs a check for that.
Grahame Grieve (Jul 17 2016 at 20:32):
I don't feel good about where this is going, mainly for process reasons
Grahame Grieve (Jul 17 2016 at 20:33):
one implication of this is that it would be possible - theoretically - for a single code system to support 2 different transitive closure relationships.
Grahame Grieve (Jul 17 2016 at 20:33):
and so you'd have to name the one you want when you invoke it.
Grahame Grieve (Jul 17 2016 at 20:34):
that's scary, particularly since we here can't even get our understanding aligned.
Grahame Grieve (Jul 17 2016 at 20:34):
and very much out of core.
Grahame Grieve (Jul 17 2016 at 20:34):
so we could say: there can only be one transitive closure relationship for each code system
Grahame Grieve (Jul 17 2016 at 20:34):
the code system defines what that is, if there is one
Grahame Grieve (Jul 17 2016 at 20:36):
it's also what is the heirarchy in the code system resource
Grahame Grieve (Jul 17 2016 at 20:36):
anything else is properties
Grahame Grieve (Jul 17 2016 at 20:38):
also, I'm not going to try and rewrite all the existing language around subsumes and closure between now and a few hours time to allow it to not be based on is-a relationships. Instead, we ad a ballot note on the terminology service that we are considering be changing the definitions of those operations to be more loose
Erich Schulz (Jul 18 2016 at 01:32):
I'm pretty sure transitive mean if there are relationships "A-B-C" and "C-B-D", and B is transitive, then it is true that "A-B-D"
Erich Schulz (Jul 18 2016 at 01:33):
so "part-of", "is-a", and "causes" are all transitive....
Erich Schulz (Jul 18 2016 at 01:33):
(although 'causes' is an odd one because it can also by cyclic...)
Erich Schulz (Jul 18 2016 at 07:35):
the one word that seems to have taken on an unusual meaning in FHIR-land is "closure"
Erich Schulz (Jul 18 2016 at 07:37):
@Robert McClure - what are the other relationships you are talking about? I have some sympathy for Grahames "keep it simple" one hierarchy (DAG woteva) per system... although poor second-class treatment that part-of gets treated with has always irked me (since about 1996 at least)
Grahame Grieve (Jul 18 2016 at 07:39):
we all hate on part-of
Erich Schulz (Jul 18 2016 at 07:40):
awww... poor old-part-of :-(
Erich Schulz (Jul 18 2016 at 07:43):
as long as there is proper labeling of which relationships are "is-a" and which are "part-of" then why can't they all just get along?
Grahame Grieve (Jul 18 2016 at 07:45):
you've never been a meeting room full of terminologists then?
Erich Schulz (Jul 18 2016 at 07:46):
not for over 18 years...
Rob Hausam (Jul 18 2016 at 13:01):
I think that what we should do is make clear that $closure and $subsumes are defined for core as operating on is-a hierarchies only. And anything else that anyone may want to do with them (not that likely, really) would be an extension. With that, a new core element shouldn't be needed (as far as I can see at the moment). This follows at least in the spirit of RDF/OWL, where, even though many relations can be transitive (they can be explicitly declared to be so), only "subclassOf" is treated as "first class” in that regard, including for the purpose of showing the hierarchy in the tooling (at least in Protege, TopBraid, etc., - I don't recall ever seeing anything else).
Grahame Grieve (Jul 18 2016 at 13:28):
the need for the element is so that a server can know whether the heirarchy is subsumption or not.
Grahame Grieve (Jul 18 2016 at 13:28):
otherwise there is no way to know
Rob Hausam (Jul 18 2016 at 14:59):
Well, what I was suggesting was that if you define subsumption as based on/scoped to is-a, then that's how you (or the server) would know. If we really need something beyond is-a, then fine - but so far I'm not really seeing it and haven't heard anything that sounds especially compelling. We can add it as an extension if someone does really want it.
Robert McClure (Jul 18 2016 at 15:48):
@Grahame Grieve I agree we need to constrain our world here, I just wanted to lay out the foundation. @Erich Schulz All I'm saying is that code systems can, and often do (SCT), define many concept relations, as as you've noted, at it's core $closure is a simplistic idea of following a defined graph to get all the nodes. So any relation defines a graph and in theory $closure should support it. But GG & RH are correct, that seems like an extension to me. I don't agree with @Rob Hausam that we should restrict this to IS-A only but I do think it's reasonable to restrict it to the relation that is to be used as "the hierarchy" for the code system. I'd say that if it's not specified it can be called something like "GroupedBy" which is meant to be anything (including IS-A). SCT defines this hierarchy as IS-A (i.e.: a subsumption hierarchy = transitive + inherited). This is important for code systems like ICD that do not use IS-A.
What I need to better understand is how the operations $closure and $subsumes are tactically different in FHIR. What is different about what they bring back to the user?
Rob Hausam (Jul 18 2016 at 16:23):
Don't know if or how much it matters, but I was referring to is-a in the FHIR sense, not specific to SNOMED CT or other particular terminologies (which may or may not have a relationship that fits into the FHIR notion of is-a, whether they actually call it that or not). @Grahame Grieve, I think we probably do need an element as you suggest, as CodeSystem doesn't really have a way to cover that at present. And I think it probably would be best to keep $closure and $subsumes applied only to subsumption (is-a) - at least for core.
Robert McClure (Jul 18 2016 at 23:16):
So what does FHIR think IS-A means? Something other than B is a one of A? Are you saying @Rob Hausam that it means some sort of general "GroupedBy"? I hope not...
Grahame Grieve (Jul 18 2016 at 23:20):
no I don't think Rob is saying that and it's not true.
Grahame Grieve (Jul 18 2016 at 23:21):
it's fine to define subsumption based on is-a. I'm fine with that. but the code system heirarchy is not defined that narrowly. all I'm asking for is to add an element so that you can say, if you know, what the heirarchy means, so a server can know whether it can do subsumption testing based on the code system instance
Grahame Grieve (Jul 18 2016 at 23:24):
at present, the underlying logic for $subumes and $closure is identical - defined to be based on subsumption. $closure embeds the logic to maintain a closure table dynamically on the server. e.g. if the client iterated through it's existing closure table doing $subsumes, it would get the same set of changes that it would get from asking the server to do a $closure - only it would be orders of magnitude slower
Robert McClure (Jul 19 2016 at 16:23):
@Grahame Grieve that all makes sense and is what I would suspect. I've agreed with your proposal to add an element that should be a defined (value?) set of named relations - the list we stated before - as a way of communicating the structure of the default hierarchy. All those relations (the most general being GroupedBy or something similar) would be treated the same of course in that "the hierarchy" would be used for the $closure operation (i.e.; would be the substrate for the closure table.) You are then proposing that $subsumes would define a closure table only for those code systems that declare the hierarchy uses IS-A? I'd say you should include Part-Of too in that.
Do I have it right?
Grahame Grieve (Jul 19 2016 at 19:02):
well, right now, $subsumes and $closure have the same meaning, and I think we like that they do. Changing $closure to be wider - which I can see the sense of - therefore implies that $subsumes should be wider. Which implies that it needs a new name. I'm fine with those things in principle, but I'm troubled by the process implications of this - we already have a dispensation to make the change to the resource in the qa freeze - I don't know that I want to rename the operation etc.
Grahame Grieve (Jul 19 2016 at 19:03):
right now, my preference would be to leave the name and the definitions of the operation the same, add a ballot note that we are considering widening them and changing the name of $subsumes, and would welcome comment about this, and add the element
Grahame Grieve (Jul 19 2016 at 19:09):
and to be specific about the element:
heirarchyMeaning : code [1..1], where code is one of
groupedBy : no particular relationship between the concepts can be assumed, except what can be determined by inspection of the definitions of the elements (possible reasons to use this: importing from a source where this is not defined, or where various parts of the heirarchy have diferent meanings)
subsumes : child elements in the heirarchy have [standard definition of subsumption from else where in fhir spec]
partOf: child elements list the individual parts of a composite whole (e.g. bodysite)
classifiedWith : child elements in the heirarchy represent more specific classification paths (often, but no always, this means subsumption; one common difference is the presence of "not otherwise classified")
Rob Hausam (Jul 19 2016 at 19:28):
@Grahame Grieve After thinking about a number of options, I think this approach makes sense. If we want to broaden the operations (one or both - we could make them logically divergent, if there is a need to do that), then $subsumes could become $is-descendant (or $is-descendant-of).
Grahame Grieve (Jul 19 2016 at 19:42):
ok, so that's what we take to Vocab
Robert McClure (Jul 19 2016 at 22:28):
I'm ok with most of that except I'd like to see the following definitions for:
ClassifiedWith - child concepts in the hierarchy may have only one parent and there is a presumption that the code system is a "closed world" meaning all things must be in the hierarchy. This results in concepts such as "not otherwise clasified."
Subsumes - A hierarchy where the child concepts are "a kind of" the parent (typically an IS-A relationship.)
Grahame Grieve (Jul 19 2016 at 22:40):
ok happy with those definitions
Rob Hausam (Jul 19 2016 at 22:50):
those definitions seem good - there possibly is some wordsmithing we can do with subsumes, but it may be fine as is
Last updated: Apr 12 2022 at 19:14 UTC
