Stream: implementers
Topic: operations on search queries
Patrick Werner (Jun 21 2018 at 13:08):
As i understand you can't combine a search and a operation like e.g. {{baseurl}}/Composition?patient=Patient/4953/$document
Patrick Werner (Jun 21 2018 at 13:20):
am i right in my understanding of the standard? I was wondering because the example above would be quite useful sometimes, the problem here seems to be $ as a composite search param <-> operation param
Alexander Zautke (Jun 21 2018 at 14:44):
The closest thing that you could do is something like: [base]/Composition?patient=Patient/4953&_query=$document
However, this is would only be possible if $document would be a named query and not an operation.
If you really need it, it would be possible to define a custom named query for it.
Alexander Zautke (Jun 21 2018 at 14:50):
Or you could start a discussion about whether or not it would make sense to allow (some) operations also as named queries :P
Patrick Werner (Jun 22 2018 at 08:32):
the idea with the named query is nice but not according to the spec, i think. Named queries have to be searches as well, and are triggered through a search [GET], whilst Operations are triggered through a POST.
Lloyd McKenzie (Jun 22 2018 at 15:41):
Operations can be triggered through GET in some cases
Alexander Zautke (Jun 23 2018 at 18:50):
The main reason behind this idea is that there is no real difference between the current OperationDefinition for $document and a named query.
From what I understand, everything could stay the same, besides changing the type to "query".
Moreover, as @Lloyd McKenzie mentioned, in cases where the operation is idempotent and only requires simple input parameters, we can also execute this operation via GET. So it would be theoretically executable it in a search environment. Additionally, $doucment is returning a bundle and is, therefore, matching the requirements for the return values of named queries as defined in section 5.4.3.4 - Executing Operations and Named Queries.
So maybe, it should be discussed if a third "kind" can be introduced which would be a mix of "query" and "operation". It would reduce the need of having to define something almost identical. This idea is just meant as some food for thought, so please don't judge it too harshly.
Grahame Grieve (Jun 25 2018 at 10:22):
why would need to define something almost identical - I followed the rest of what you wrote, but I din't see about that
Alexander Zautke (Jun 25 2018 at 13:49):
It was meant in reference to the current approach. To make the search request work, you need to define the named query, which is almost identical to the already defined $document operation.
Patrick Werner (Sep 14 2018 at 12:47):
I gave this issue another thought and still think that it has its usecase.
{{baseurl}}/Composition?patient=Patient/4953/$document
{{baseurl}}/ValueSet?url=http://hl7.org/fhir/ValueSet/administrative-gender/$expand
are both examples where it would be very useful to be able to chain query with an operation. It safes you a http request. I know i could do the expanse with a POST with a Parameter Object, chaining queries with operations seems to be the more elegant way.
Stefan Lang (Sep 19 2018 at 07:50):
Being able to combine search and an operation for sure is useful in some, probably many, cases. For such a "conditional operation", it would have to be clarified what would happen in the cases of zero/one/many matches. It might be necessary to define that differently for each operation. And in the first place, define which operations should be supported here.
Also it might be necessary to extend OperationDefinition eccordingly.
I think that it's worth to further detail the idea.
Eric Haas (Sep 19 2018 at 16:19):
I defined in my operation the search parameters you can use with it. e.g. _count
Patrick Werner (Sep 19 2018 at 16:35):
@Eric Haas So you did add search parameters to the operation as parameters? This could be a solution, but you have to build your own operation+operation implementation.
Patrick Werner (Sep 19 2018 at 16:36):
Looking at the Examples above ($expand, $document) i simply want to be able to chain a search with an operation. This safes a Roundtrip to the server.
Patrick Werner (Sep 19 2018 at 16:37):
I don't think building operations, or named queries based on existing operations is very elegant. It duplicates logic and code.
Patrick Werner (Sep 19 2018 at 16:38):
as @Stefan Lang mentioned: if we want to chain searches with operations (working title: Conditional Operation), we have to select which operations could be supported and define the output of the search (none|one|many).
Patrick Werner (Sep 19 2018 at 16:39):
I would be happy to let the operation fail if zero, or many results are returned from the search. Of course this would be only applicable to operations on a single resource
Eric Haas (Sep 19 2018 at 16:40):
So you did add search parameters to the operation as parameters?
NO here is my example .... http://www.fhir.org/guides/argonaut/scheduling/OperationDefinition-appointment-find.html
In the notes I added
"To set the upper limit on the total number of available appointment options to return use the standard _count search parameter. See the examples below for how this is implemented.
Using Both GET and POST Syntax the operation can be invoked as follows:
GET [base]/Appointment/$find?{parameters}&?{_count}
POST [base]/Appointment/$find?{_count}"
is this what you were looking to do?:
Stefan Lang (Sep 19 2018 at 16:43):
I think _count is a different case here, since it is not a search parameter, but just defines the number of entries in the returning bundle
Patrick Werner (Sep 19 2018 at 16:48):
no i wanted to be able to something like this:
{{baseurl}}/Composition?patient=Patient/4953/$document
{{baseurl}}/ValueSet?url=http://hl7.org/fhir/ValueSet/administrative-gender/$expand
Yunwei Wang (Sep 19 2018 at 19:30):
the 2nd one, $expand defines an input parameter "url". So it should be
{{baseurl}}/ValueSet/$expand?url=http://hl7.org/fhir/ValueSet/administrative-gender
Patrick Werner (Sep 19 2018 at 20:05):
i know, but maybe i'm selecting the ValueSet i'd like to expand by another search query. The question to me remains, why is a operation on a search result not valid. So i can chain search and operation in one request. Adding similar functionality to operations as input parameters seems more work to me and duplicating search mechanisms inside of the operation.
Grahame Grieve (Sep 21 2018 at 04:01):
this kind of thing is on my todo list but (a) it's actually really hard and (b) my todo list keeps getting knocked around
Yunwei Wang (Sep 21 2018 at 14:17):
Most operation is on single instance and search returns a list of instance in a bundle. Do we want to apply operation to all of them? For example, do we want to generate document for all male patients when such request come in:
{{baseurl}}/Composition?patient.gender=male/$document
Patrick Werner (Sep 21 2018 at 14:52):
As @Stefan Lang mentioned earlier: you could see this as a "conditional" operation, or as a chained operation behind a searchQuery. So you have to define what kind of input your are expecting.
For $document this could be:
- 0 found -> Error
- 1 found -> create DocumentBundle
- 2-* found -> create a SearchBundle with one document for each found composition _OR_ Error as we want to expect only one.
This would be up for definition/discussion
Patrick Werner (Sep 21 2018 at 14:53):
If i can support this process in any way, let me know @Grahame Grieve
Alexander Zautke (Sep 21 2018 at 14:55):
Due to the fact that $document itself returns a search bundle, we might want to return an empty bundle if we have 0 matches. I fully support the rest of the proposal :)
Stefan Lang (Sep 21 2018 at 15:46):
Right, the easiest, and probably most transparent, way would be returning a searchset bundle with the operation applied to each resource within that bundle. This would avoid the 0/1/many cases - from an implementation point of view just an iteration over all results of the search, so probably easier to implement.
This for sure would work for $document, still not sure if that would apply for all, or at least for all idempotent operations (not checking, just guessing at the moment)
Patrick Werner (Nov 19 2018 at 17:54):
after discussing this during a breakout at the devdays18 in AMS, we came to the following solution:
Patrick Werner (Nov 19 2018 at 17:54):
flipchart_devDays_breakout.pdf
Patrick Werner (Nov 19 2018 at 17:59):
To enable the functionality of operations on search results a new operation has to be defined.
This operation takes as input parameters:
- 0..1 search params string to define the search critereas
- 1..* operation names. Multiple operations can be chained, the output of the first operation is used as the input of the second
Ewout Kramer (Nov 20 2018 at 13:47):
Sounds like a pipelining mechanism. Before you know it you want to execute a third step after, say, searching and expanding and then limiting the output with _summary. In that case, it would be interesting to consider using a batch Bundle containing the operations - but instead of the output of the steps going into the response Bundle, they would go into the next step in the batch - the output is the result of the last step. I am knowlingly skipping a lot of steps here, just try see how far I can push this ;-)
Grahame Grieve (Nov 21 2018 at 05:06):
the trouble with this - and I've been thinking about this quite a bit - is that the input and output are not the same type. So you'd have to specify some complicated transform between b and c. This operation is very specifically limited to avoid that - the output of a is a list of resources, and the input for b is a single resource, and the operation is defined as an iterator
Ewout Kramer (Nov 21 2018 at 11:58):
Yes, and the _summary is defined on a search, but if you'd like to do a _summary on the previous step, you need some kind of identity search.
Patrick Werner (Jan 15 2019 at 17:52):
here is the current state of the discussion @Yunwei Wang
Alexander Zautke (Jan 19 2019 at 10:53):
Does someone has any suggestions for a good name for this operation, btw?
Patrick Werner (Jan 23 2019 at 13:19):
searchOp or opSearch?
Standing for operation(s) on search queries
Last updated: Apr 12 2022 at 19:14 UTC
