Stream: terminology
Topic: GF#16245
Grahame Grieve (Jul 26 2018 at 21:01):
@Bob Dolin - we must resolve task GF#16245 next week or defer it. Your comment: "Is there a time when Aziz and I can attend the Vocab call and discuss this? We'd like to explain our rationale for why we feel the current service is too time costly, making it difficult to use for real-time checking." - please make your comments here
Grahame Grieve (Jul 26 2018 at 21:02):
I'm not sure how you'll persuade us to change the definition of an API because a particular implementation has a performance issue...
Grahame Grieve (Jul 26 2018 at 21:03):
also @Aziz Boxwala
Aziz Boxwala (Jul 26 2018 at 21:20):
@Grahame Grieve : The API asks the question what is the relationship between two concepts A and B, with the possible answers being A is subsumed by B, B is subsumed by A, A = B, or A is not-subsumed by B. For CDS purposes, I typically only care if A is subsumed by B. All other responses are the same as A is not subsumed by B. Our server performance is not the concern, but trying to determine the other relationships when don't need to, is taking up valuable milliseconds. From the perspective of our use case, the API is asking the wrong or too broad a question. Our current implementation of the API does not bother to determine equivalence or the reverse relationship, which then does not conform fully to the API. We'd very much like to have the option to only answer whether A is subsumed by B in this API and be considered conformant. Or do you think we should propose a new API?
Grahame Grieve (Jul 26 2018 at 21:24):
if a = b then a is subsumed by b, yes?
Aziz Boxwala (Jul 26 2018 at 21:28):
Possibly, but in practice, I probably won't encounter that scenario. We use the API to determine class of medications or categories of problems, for example.
Also, if B is subsumed by A, then A is not subsumed by B. So there is some overlap/ambiguity in the response valueset.
Grahame Grieve (Jul 26 2018 at 21:30):
I don't know why you won't encounter that problem with medications or problems - both are subject to multiple ways of saying the same thing
Grahame Grieve (Jul 26 2018 at 21:30):
agree that the definition of A is not subsumed by B is problematic.
Grahame Grieve (Jul 26 2018 at 21:33):
the API allows for the determination of the reverse response because in some cases, this saves the client from asking the follow up question in the reverse direction
Aziz Boxwala (Jul 26 2018 at 21:33):
Typically, we'd ask if <problemcode from problemlist> is subsumed by <classcode>. Generally, there is good separation of the codes in patient records to class codes, though it is possible. So, I'll stop arguing since we want to cover the general scenario :-)
Grahame Grieve (Jul 26 2018 at 21:36):
does any one else have any comment? @Michael Lawley you have a scale implementation of this..? (my implementation it doesn't take any longer to figure out the answer either way)
Aziz Boxwala (Jul 26 2018 at 21:36):
the API allows for the determination of the reverse response because in some cases, this saves the client from asking the follow up question in the reverse direction
Should that be an option in the request, i.e., a flag that is set to true to also ask the reverse question. This way, one can optimize if needed.
Aziz Boxwala (Jul 26 2018 at 21:43):
does any one else have any comment? @Michael Lawley you have a scale implementation of this..? (my implementation it doesn't take any longer to figure out the answer either way)
Our implementation uses a directed graph, so the reverse relationship becomes a second query.
Michael Lawley (Jul 26 2018 at 22:04):
We're with @Grahame Grieve on the implementation cost. It's a trivial bit of extra to populate the result object, but no extra effort to check.
Michael Lawley (Jul 26 2018 at 22:06):
Being able to distinguish subsumed from strictly subsumed (ie <= from <) is often important for the client
Michael Lawley (Jul 26 2018 at 22:08):
If you've got really high volume uses then $closure may be a better option
Michael Lawley (Jul 26 2018 at 22:59):
(some figure from yesterday when a local university was hitting our public server - nearly 500,000 $subsumes calls (via POST, so no caching) with an average of 1.78ms per call; faster than $lookup which is averaging at 2.7ms)
Grahame Grieve (Jul 27 2018 at 21:21):
one way to resolve this is to restructure the return codes, so the choices are:
-
subsumes
** equivalent -
not subsumed
** subsumed-by
** disjoint
Michael Lawley (Jul 27 2018 at 21:44):
Equivalent would normally be a child of subsumed-by as well. The above requires subsumed-by to mean strictly-subsumed-by
Grahame Grieve (Jul 27 2018 at 21:45):
Equivalent would normally be a child of subsumed-by as well
Grahame Grieve (Jul 27 2018 at 21:45):
uh why?
Grahame Grieve (Jul 27 2018 at 21:45):
umm no, wrong question:
Grahame Grieve (Jul 27 2018 at 21:46):
"strictly-subsumed-by" .. means... ?
Rob Hausam (Jul 27 2018 at 21:48):
strictly subsumed by would mean that A is truly a specialization of B - not equivalent
Grahame Grieve (Jul 27 2018 at 21:55):
ok, then, I'm not sure that it does require that
Rob Hausam (Jul 27 2018 at 21:57):
I think that what Michael is getting at is that if you take subsumes to mean "include self", then equivalent concepts subsume each other - if you don't want that, then you have to define subsumption "strictly" to require specialization
Michael Lawley (Jul 27 2018 at 21:59):
Subsumed-by includes equivalent, so equivalent would also be a child of subsumed-by, but this would conflict with the ancestor not-subsumed.
But really, this approach just re-introduces the original problem: if a client wants to distinguish strictly subsumed from equivalent then it needs to make two calls.
This will always be far more costly than any overhead of having the server return a precise answer even when the client doesn't care.
Rob Hausam (Jul 27 2018 at 22:00):
right
Rob Hausam (Jul 27 2018 at 22:08):
Except that for $subsumes in the concept-subsumption-outcome value set we've defining subsumes and subsumes-by strictly (i.e. requiring additional properties). That's not the case for the is-a filter operator, which includes self (but we also have descendent-of which doesn't).
Rob Hausam (Jul 27 2018 at 22:21):
Back to the resolution for this issue, I'm still inclined toward the arguments that @Grahame Grieve and @Michael Lawley are making to stay with the proposed resolution and the current four codes in the value set which cover the possible outcomes.
Grahame Grieve (Jul 27 2018 at 22:28):
I'm looking for a way for a server to do a partial implementation without having to lie.
Grahame Grieve (Jul 27 2018 at 22:28):
I do not follow this logic: Subsumed-by includes equivalent, so equivalent would also be a child of subsumed-by
Grahame Grieve (Jul 27 2018 at 22:29):
that would depend on the definitions
Michael Lawley (Jul 27 2018 at 22:40):
If a server can do a partial implementation then clients that need to dIstInguish always have to cater for that and thus always need to do two calls to separate equivalent from subsumed-by/subsumes.
I don't see a way around that.
Grahame Grieve (Jul 27 2018 at 22:44):
if the server does it in one, it returns one of the specific codes, and you don't need to make a follow up call
Rob Hausam (Jul 27 2018 at 22:50):
yes
Michael Lawley (Jul 28 2018 at 07:44):
but with the hierarchy above, subsumes is not a specific code
Last updated: Apr 12 2022 at 19:14 UTC
