Stream: terminology
Topic: rename $compose to $find-matches
Grahame Grieve (Jul 26 2018 at 10:05):
GF#15956 said, in the disposition, to actually rename $compose as previously agreed. But when I went through the records, I discovered that agreed that we would rename it, but not what we would rename it to. So I have renamed it to $find-matches. Opinions welcome
Peter Jordan (Jul 26 2018 at 10:20):
I can't find the original thread relating to this either, but recall suggesting $match without gaining any support. I did implement this, in part for exact matches in SNOMED CT, but that's possibly been superseded by the new ecl query option for implicit value sets. It would be interesting to hear if others have implemented and found value in this operation.
Michael Lawley (Jul 26 2018 at 10:25):
I note that the operation is showing a maturity level of 5 - clearly this is an oversight
Michael Lawley (Jul 26 2018 at 10:32):
We have not implemented the operation, and have not had anyone ask us for this functionality. As Peter says, it's largely obviated by ECL for snomed ct (augmented by a text search capability). I suspect that it might be useful for LOINC, but we've seen little use of loinc with Ontoserver so far.
I would welcome any use cases from people that could help with validating ImplementatiIna of the current proposal.
Brian Postlethwaite (Jul 26 2018 at 11:02):
Just a note that Patient describes a $match operation too, that was intended to potentially be generic too (nothing really specific to patient)
http://hl7.org/fhir/patient-operations.html#match
You pass it an instance (or partial) and the operation will treat it like a search, and find instances that are potential matches for it
Grahame Grieve (Jul 26 2018 at 11:03):
I would've called it $match if it wasn't for that. And I don't see how ECL obviates the need for the API. personally.
Grahame Grieve (Jul 26 2018 at 11:03):
it might be logical way to implement it for SCT...
Rob Hausam (Jul 26 2018 at 12:51):
$find-matches seems probably as reasonable as anything and should accomplish the goal of not being confused with ValueSet.compose
Michael Lawley (Jul 26 2018 at 14:17):
Only obviated for SCT, not for CodeSystem in general. I like $find-matches; for me it's much more indicative of its behaviour
Grahame Grieve (Jul 26 2018 at 23:16):
I still don't understand how you think ECL obviates an API operation. Perhaps it's more than I think...
Peter Jordan (Jul 27 2018 at 00:31):
The (SCT-only) question for me is what might a $find-matches operation be able to return that can't be found using an ECL-based filter in the (implicit) ValueSet $expand operation?
Grahame Grieve (Jul 27 2018 at 00:33):
if you have precise sct properties values, then probably nothing. Except that client has to know how to construct the ECL
Grahame Grieve (Jul 27 2018 at 00:33):
where as with the find matches API, the client assembles what it has, and delegates the whole lot to the server, and can accept possible matches. This is quite a different thing
Peter Jordan (Jul 27 2018 at 00:41):
Understood, but the client still has to have a certain degree of knowledge about SCT properties, including relationship groups, to make a $find-matches request. For this, or ECL, a client application might need a UI processing component that could convert dropdown selections into FHIR API calls.
Grahame Grieve (Jul 27 2018 at 01:06):
only what to provide...
Michael Lawley (Jul 27 2018 at 01:13):
Constructing the ECL is the tricky part, but the current spec is pretty wide open as to how loose the match can be when exact is false.
I presume one always wants at least one property to be present?
There's a bunch of interpretation still open as to what exact means in the presence of multi-valued properties. eg if I ask for an exact match for site = appendix, and action = excision then I would expect all partial matches to have at least one of those values matching, but what about subtypes of appendix? or direct-site / indirect-site which are subtypes of site?
Should a client expect an "exhaustive" list of matches, or maybe just n of the "best" matches?
Grahame Grieve (Jul 27 2018 at 02:06):
right. that's why it's maturity level 0. I'm just pointing out that ECL is not a functional replacement, though it's semantically doing some very similar
Michael Lawley (Jul 27 2018 at 02:49):
Yep - my initial stab at trying to understand the semantics & boundaries of this API was an attempt to translate it to ECL (assuming SCT).
I quickly ran into all these questions about how strict the matching should be. Without knowledge of any use-cases to inform me of what might be practically useful I've been unable to make any progress.
Grahame Grieve (Jul 27 2018 at 02:53):
maybe we can talk about this a little next week when ftf
Peter Jordan (Jul 27 2018 at 03:15):
GF#17563 request to correct remaining references to $compose operation in the $find-matches operation page.
Grahame Grieve (Jul 27 2018 at 03:23):
oops thanks
Last updated: Apr 12 2022 at 19:14 UTC
