Stream: implementers
Topic: Search parameters
Shlomy Reinstein (Nov 16 2016 at 15:57):
I'm using HAPI FHIR server with DSTU2, and it provides a set of search parameters that do not always match the name of the resource element. For example, if I want to query the Observations of a specific patient, I use "?patient=...", while the field is actually named "subject". Are the names of search parameters fixed in the FHIR standard? If not, how do I know which names to use when querying by a certain field, and how do I know which fields can be searched?
Lloyd McKenzie (Nov 16 2016 at 16:03):
If you look at the bottom of each resource page, you'll see the list of available search parameters, including maps that identify the paths within the resource that correspond to each parameter name. Do note that the names on a particular server can be different still (generally to address name collisions) - you need to look at the Conformance/CapabilityStatement of the server to see what search parameters it actually supports and what names it uses for them.
Shlomy Reinstein (Nov 16 2016 at 17:00):
Thanks! I somehow missed this part in the FHIR specification.
Shlomy Reinstein (Nov 16 2016 at 17:04):
However, the fact that each server may support a different subset of search parameters, means that apps that use specific search parameters may need to take into account that they may work with some servers but not with others, unless they support both cases. If I want to search all Observations of a specific patient ordered by date, but the server does not support the date parameter, then the application must read all the Observations and sort the list on its own. It's a lot of overhead on the application, if it's intended for use with different servers. Is there a platform / library that creates this abstraction, so you can search by the full set of parameters even if the server does not support it?
Lloyd McKenzie (Nov 16 2016 at 19:48):
Yes. However, keep in mind that servers can also choose which elements to support in resources (both what core elements and what extensions). They can also choose what resources they'll support, what operations they support, whether they support chaining, includes, sorting and a whole raft of other things. There are no guarantees that an arbitrary server will do *anything* a given client needs. There are several possible client design strategies:
1. Assume support for whatever functionality you need and only function with those servers that provide it. (Simplest, limits what servers you'll work with)
2. Assume bare minimum server support and take on everything else internally (less efficient, slower)
3. Query to find out what a given server supports, make them do as much of the work as they're capable of, then handle the rest internally. (most efficient, maximizes interoperability, much more effort to write and test)
4. Look to implementation guides to set expectations for servers in a particular interoperability space and develop clients according to those expectations. (Ideal if all the servers you need to talk to support the implementation guide and the implementation guide covers your needs.)
nicola (RIO/SS) (Mar 06 2017 at 14:07):
Hi, have we merged SearchParameters for several resources into one:
1332 "base": [ 1333 "FamilyMemberHistory", 1334 "AllergyIntolerance", 1335 "Procedure", 1336 "List", 1337 "DiagnosticRequest", 1338 "DeviceUseRequest", 1339 "Observation", 1340 "DiagnosticReport", 1341 "Condition" 1342 ], 1343 "type": "token", 1344 "description": "Multiple Resources: \r\n\r\n* [FamilyMemberHistory](familymemberhistory.html): A search by a condition code\r\n* [Allergy 1345 "expression": "FamilyMemberHistory.condition.code | AllergyIntolerance.code | AllergyIntolerance.reaction.substance | Procedure.code | Li 1346 "xpath": "f:FamilyMemberHistory/f:condition/f:code | f:AllergyIntolerance/f:code | f:AllergyIntolerance/f:reaction/f:substance | f:Proced 1347 "xpathUsage": "normal" 1348 }
for disk space economy? It looks little bit messy :(
nicola (RIO/SS) (Mar 06 2017 at 14:10):
What is the reason for such change? Why many to many Resource*-*SearchParam, why not clear and granular Resource-*SearchParam?
James Agnew (Mar 06 2017 at 15:31):
I was wondering about this too.
Also, does the xpath part still serve any purpose? Are there any paths that can only be expressed with xpath and not with fhirpath?
nicola (RIO/SS) (Mar 06 2017 at 15:33):
Now we have to split it back by hands :( parsing expression and/or xpath
nicola (RIO/SS) (Mar 06 2017 at 15:35):
My initial perseption was, that SearchParameters with multiple base and complex expressions was introduced for global searches :)
Lloyd McKenzie (Mar 06 2017 at 19:28):
@nicola (RIO) That's exactly why - these are the parameters you can use for searching against the base endpoint to bring back resources of different types.
Grahame Grieve (Mar 06 2017 at 20:00):
Xpaths are redundant if you support fhirpath. But we are maintaining xpaths as a convenience for implementers who do not have a implementation of FHIRPath and want to use xpath
nicola (RIO/SS) (Mar 06 2017 at 20:12):
But I do not see specific searchparams like patient-given - or we have to deduce it from group search?
Grahame Grieve (Mar 06 2017 at 20:34):
{
"resourceType": "SearchParameter",
"id": "individual-given",
"url": "http://hl7.org/fhir/SearchParameter/individual-given",
"name": "given",
"status": "draft",
"experimental": false,
"date": "2017-03-06T17:39:13+11:00",
"publisher": "Health Level Seven International (Patient Administration)",
"contact": [
{
"telecom": [
{
"system": "url",
"value": "http://hl7.org/fhir"
}
]
},
{
"telecom": [
{
"system": "url",
"value": "http://www.hl7.org/Special/committees/pafm/index.cfm"
}
]
}
],
"code": "given",
"base": [
"Practitioner",
"Patient"
],
"type": "string",
"description": "Multiple Resources: \r\n\r\n* [Practitioner](practitioner.html): A portion of the given name\r\n* [Patient](patient.html): A portion of the given name of the patient\r\n",
"expression": "Practitioner.name.given | Patient.name.given",
"xpath": "f:Practitioner/f:name/f:given | f:Patient/f:name/f:given",
"xpathUsage": "normal"
}
Grahame Grieve (Mar 06 2017 at 20:34):
deduce from the fact that given is defined for both Practitioner and Patient
nicola (RIO/SS) (Mar 06 2017 at 21:01):
Sounds strange ;( may be I am only one, who don't like it. Specific search is more important for me, then multi-resource search. Granularity of control for specific parameter also sacrificed.
John Moehrke (Mar 06 2017 at 21:54):
We have "Compartment" simplification. Grouping beyond those compartments seems might be more trouble. right?
Lloyd McKenzie (Mar 06 2017 at 22:13):
@nicola (RIO) You should still have granularity in your CapabilityStatement as you can declare support (or not) for each SearchParameter on a per-resource basis.
nicola (RIO/SS) (Mar 07 2017 at 08:56):
@Lloyd McKenzie i am afraid, that such changes complicate standard perception - FHIR becoming more and more complicated - it's very uneasy to explain mixed concepts, like group search parameter which also describe specific search - let's look for simplicity :)
Lloyd McKenzie (Mar 07 2017 at 18:09):
The declaration of support for a given search parameter for a given resource has always been in the Conformance/CapabilityStatement - that's not a change. I believe support for cross-resource search was part of the ballot. The community can (and should) speak out against functionality they don't want in the spec/excessive complexity. And it's certainly possible to request reversal in the next release if implementer experience suggests the current design is too painful.
Dave Barnet (Jul 05 2018 at 09:52):
We have a use case where we have a set of Condition resources bound by a List kept on a FHIR server. There can be new Conditions attached to the List, and Conditions may become inactive. When we GET the conditions for a given List, it would be useful to get just the active conditions. Active conditions are those with a Condition.clinicalStatus of "active", when Conditions become inactive, the Condition.clinicalStatus is set to "inactive (as well as the List.entry.deleted flag set to "true").
It would be really useful if we could query the server to GET a specified List, and just the active Conditions associated with the List. So a query like
GET [serverReference]List?_id=[myList]&_include=List:item&item:Condition.clinical-status=active
However, this doesn't work (you get back ALL conditions associated with the List regardless of their clinical-status). I'm assuming that
_id=[myList] works OK as I just get [myList] back
_include=List:item works OK as I get back all the resources (Conditions) referenced by item
item:Condition.clinical-status=active doesn't work as a chaining statement is all about influencing which resources being queried (in this case List) are returned and not about influencing the referenced resources (in this case Condition).
Is there a GET statement that would get the List and ONLY active Condition referenced by the List? Or is it just a client side activity to filter out the inactive Conditions?
Grahame Grieve (Jul 05 2018 at 12:04):
you'd have to use _filter for that
Dave Barnet (Jul 06 2018 at 11:01):
Do you know of a test server that has implemented _filter (the vonk server says "Parameter _filter is not implemented"? Is there some open source code that implements _filter?
Grahame Grieve (Jul 06 2018 at 11:20):
test.fhir.org does. and I think I convinced James to add it to HAPI but it's not done yet
Grahame Grieve (Jul 06 2018 at 11:20):
@Christiaan Knaap is this on your roadmap?
Dave Barnet (Jul 06 2018 at 13:12):
We've just had a look at test.fhir.org & it looks like you haven't implemented the _include parameter, so that makes testing of _filter for our use case difficult.
Grahame Grieve (Jul 06 2018 at 13:19):
i definitely have implemented _include
Dave Barnet (Jul 06 2018 at 14:20):
Sorry - yes you have
Christiaan Knaap (Jul 10 2018 at 06:42):
@Grahame Grieve : It is, but not on the short term that I hoped for. But if a customer has a special request for this, it may move closer.
Christiaan Knaap (Jul 10 2018 at 07:04):
@Dave Barnet :As for the original query. I think you can do without _filter:
GET https://vonk.fire.ly/Condition?_list=02b9f75f-6a2e-494f-a504-539abc59c611&clinical-status=active
This just does not give you the List itself, but you can:
- get that in a separate GET <base>/List/<id>,
- get it together in a Batch with the two GETs
- get it with a _revinclude (but that may include other Lists that the same Condition is an item of): &_revinclude=List:item
Note: I used a specific List id, that will not exist on the demo server forever.
Last updated: Apr 12 2022 at 19:14 UTC
