Stream: implementers
Topic: SearchParameters and Extensions
Saul Kravitz (May 30 2019 at 00:51):
Any insight into how I am misusing the SearchParameter would be greatly appreciated.
I'm trying to develop a SearchParameter that will allow me to search against data in extension fields.
The extensions are valueBooleans.
I have two MedicationInformation Objects, one with the extension data, one without: (see http://hapi.fhir.org/baseR4/MedicationKnowledge)
1) http://hapi.fhir.org/baseR4/MedicationKnowledge/SaulExperimentMK1 -- has extensions
2) http://hapi.fhir.org/baseR4/MedicationKnowledge/SaulExperimentMK2
The quantityLimit extension looks like this:
{
"url": "https://api-v8-r4.hspconsortium.org/DrugFormulary2/open/StructureDefinition/usdrugformulary-QuantityLimit-extension",
"valueBoolean": true
}
I have defined a SearchParameter: http://hapi.fhir.org/baseR4/SearchParameter/quantityLimit
{
"resourceType": "SearchParameter",
"id": "quantityLimit",
"meta": {
"versionId": "1",
"lastUpdated": "2019-02-22T08:37:56.297+00:00"
},
"title": "quantityLimit",
"status": "active",
"code": "quantityLimit",
"base": [
"MedicationKnowledge"
],
"type": "string",
"expression": "MedicationKnowledge.extension(\" https://api-v8-r4.hspconsortium.org/DrugFormulary2/open/StructureDefinition/usdrugformulary-QuantityLimit-extension.valueBoolean \")",
"xpathUsage": "normal",
"comparator": [
"eq"
],
"search": {
"mode": "match"
}
}
The SearchParameter is recognized by the server, but doesn't work (as intended).
Searching:
1) http://hapi.fhir.org/baseR4/MedicationKnowledge?quantityLimit - returns two MedicationKnowledge objects... only one object has the quantityLimit extension, so this should return only one object, right?
2) http://hapi.fhir.org/baseR4/MedicationKnowledge?quantityLimit="true" returns zero objects, but should return one object, right?
Grahame Grieve (May 30 2019 at 01:01):
I don't think that HAPI automatically implements search parameter definitions- you should ask on the HAPI stream
Saul Kravitz (May 30 2019 at 14:02):
HAPI (I've tested 3.7 and 3.8) implement search parameter definitions.
See http://hapi.fhir.org/baseR4/MedicationKnowledge?productType for a search parameter that allows search against the MedicationKnowledge productType field.
A sample query is:
http://hapi.fhir.org/baseR4/MedicationKnowledge?productType=BRANDX
Moving to #HAPI stream.
Glory Kim (Jun 13 2019 at 23:13):
Is there a precedence/hierarchy in the order of search result parameters ie. should _sort always go before _count? I'm trying to understand the implementation of the search results parameters.
Lloyd McKenzie (Jun 13 2019 at 23:15):
Order doesn't matter - and should have no impact on results.
Lloyd McKenzie (Jun 13 2019 at 23:15):
(Though that's not true for multiple repetitions of the _sort parameter - there order matters)
Jean Duteau (Jun 13 2019 at 23:17):
Order doesn't matter - and should have no impact on results.
I'll agree with you but it is conceivable that _sorting first and then _counting could give you different results from _counting and then _sorting. If the server retrieved 1000 results in some random order and returned the first 100 sorted by X, that's different than retrieving 1000 results, sorting by X, and returning the first 100. If we're saying that order SHALL not have an impact on results, then I think we need to define a parameter precedence, i.e. sort first and then count.
Glory Kim (Jun 13 2019 at 23:19):
To clarify, I mean the order of implementation. For example, w/ AllergyIntolerance?_sort=AAA&_count=AAA&_include=AAA, it seems that the resources first get sorted, and then the count applies to the primary resource, and then the include works upon the resource afterwards. There doesn't seem to be any written precedence on fhir spec stating which param should be enacted first.
@Jean Duteau I agree - i think there should definitely be a parameter precedence.
Glory Kim (Jun 13 2019 at 23:21):
Perhaps there already is a written document, and I just missed it?
Jean Duteau (Jun 13 2019 at 23:26):
Perhaps there already is a written document, and I just missed it?
I just read the page on search parameters and there is nothing really there. There is this one line that implies that sorting occurs first and then paging:
Note: The combination of _sort and _count can be used to return only the latest resource that meets a particular criteria - set the criteria, and then sort by date in descending order, with _count=1. This way, the last matching resource will be returned.
Is it only really _sort and _count that need a precedence?
Jean Duteau (Jun 13 2019 at 23:29):
To clarify, I mean the order of implementation. For example, w/ AllergyIntolerance?_sort=AAA&_count=AAA&_include=AAA, it seems that the resources first get sorted, and then the count applies to the primary resource, and then the include works upon the resource afterwards. There doesn't seem to be any written precedence on fhir spec stating which param should be enacted first.
One thing I did find was that _include only occurs after paging:
When search results are paged, each page of search results should include the matching includes for the resources in each page, so that each page stands alone as a coherent package.
Glory Kim (Jun 13 2019 at 23:42):
I would say all of the results parameters should/could have a precedence
Glory Kim (Jun 13 2019 at 23:52):
Also, does anyone know how multiple _includes would work without :iterate?
Grahame Grieve (Jun 14 2019 at 01:06):
I don't understand the precendence issue. Sort and count are unrelated - sorting does not change the count
Michele Mottini (Jun 14 2019 at 02:22):
..and _count does not apply to includes
Glory Kim (Jun 14 2019 at 02:29):
Okay, thank you. So then, the order is to _sort & _count on the main resources, and then _includes resources is tacked on at the end (not sorted) ?
Grahame Grieve (Jun 14 2019 at 02:42):
yes. includes is only the includes for the page being returned. Count is the size of the page; the order returned will obviously change which page contains which result but that isn't related to the order the parameters are specified in, and the only rule on the server side is that search has to work as specified
Jean Duteau (Jun 14 2019 at 04:54):
I don't understand the precendence issue. Sort and count are unrelated - sorting does not change the count
I gave you the example. _sort:name&_count:100 : does this mean that I sort the resources by name and then give you back the first 100? Okay, then _count:100&_sort:name : does this mean that I take the first 100 resources returned randomly and then sort by name within that 100? We are mostly silent on which you do first. And if the answer is that you always _sort first and then _count, then there is an implicit precedence that we should probably state. I mean, it's pretty self-evident, but it might bear stating.
Lloyd McKenzie (Jun 14 2019 at 14:37):
Order of operations is not driven by order in the URL - with the exception of sort. First all filters are applied, then the result set is sorted, then paging is applied, and includes/revincludes are returned for each page. Agree we should make that explicit in the spec. Can you submit a change request @Jean Duteau ?
Grahame Grieve (Jun 14 2019 at 21:29):
well, we could be explicit that sorting is applied before paging, but I really thought this was super obvious
Grahame Grieve (Jun 14 2019 at 21:30):
we are explicit about includes already btw
Last updated: Apr 12 2022 at 19:14 UTC
