Stream: implementers
Topic: Searching Extension Values
Steffen Lehnert (Nov 04 2019 at 11:51):
Hi,
I am currently looking for a way to search the values of extensions and I'm a bit stuck using the official documentation and test servers.
Assuming that there is a dateTime-extension with the ULR "http://fhir.de/StructureDefinition/gkv/einlesedatum-karte/0.2" on the Coverage-resource, how would I search for a resource where this extension has a value of "2012-07-08" for example?
Would this be correct:
[ServerURL]/Coverage?_extension=http://fhir.de/StructureDefinition/gkv/einlesedatum-karte/0.2|2012-07-08
?
Furthermore, how would I search for resources where this timestamp is before "2012-07-08"? Something like this:
[ServerURL]/Coverage?_extension=http://fhir.de/StructureDefinition/gkv/einlesedatum-karte/0.2|lt2012-07-08
?
Any advice or feedback is very much appreciated!
Cheers,
Steffen
René Spronk (Nov 04 2019 at 11:57):
None of the above. To query for an extension value, you'd need to talk with your FHIR-server, to get them to agree to add another (custom) serach parameter, e.g. 'einlesedatum-karte'. That way, your quary would be Coverage?einlesedatum-karte=2012-07-08. But all of this preassumes you can configure the server to support the additional query parameter.
Steffen Lehnert (Nov 04 2019 at 12:43):
Thanks for the information!
Isn't that approach a bit cumbersom?
I mean, it requires the people creating profiles and extensions to also create those SearchParameters and to configure whatever server you are using?
Lloyd McKenzie (Nov 04 2019 at 14:22):
Do you have ideas on how to have servers support arbitrary search criteria (particularly when their internal persistence model isn't FHIR)? We'd be happy to have a workable solution, but so far no one's come up with one.
David Hay (Nov 04 2019 at 17:19):
BTW - hapi has a neat feature where you save a SearchParameter resource, and it subsequently supports that search. Works on extensions too IIRC...
Lloyd McKenzie (Nov 04 2019 at 17:33):
HAPI has the benefit of having a FHIR-based persistence layer. (And that approach only works if the search parameters are 'simple' ones. (I.e. not 'sounds like' or some other more complex matching algorithm)
David Hay (Nov 04 2019 at 17:45):
indeed - but kinda cool anyway!
Grahame Grieve (Nov 04 2019 at 19:35):
it requires the people creating profiles and extensions to also create those SearchParameters and to configure whatever server you are using
no and yes. It does not require people to create search parameters, though that is useful. It does definitely require to configure whatever server. We did that deliberately since a foundation of FHIR search is that the server decides in advance what element it allows search on , so that it can have a prepared search strategy.
Thomas Tveit Rosenlund (Nov 11 2019 at 10:03):
BTW - hapi has a neat feature where you save a SearchParameter resource, and it subsequently supports that search. Works on extensions too IIRC...
Does it really do this?
The R4 base server have some SearchParameters defined. But they are not supported when you try to search on them. I tried this one:
http://hapi.fhir.org/baseR4/SearchParameter/22788/_history/1
I woult think this means a search like this would be supported:
http://hapi.fhir.org/baseR4/DiagnosticReport?imagingStudy=ImagingStudy/23
But it don't support that search.
Jens Villadsen (Nov 11 2019 at 20:45):
For HAPI you can use a special feature to add a custom search parameter if that is what you want
Thomas Tveit Rosenlund (Nov 15 2019 at 18:37):
For HAPI you can use a special feature to add a custom search parameter if that is what you want
And today it works. I also added a search parameter for the no-basis-middlename to the HAPI test server, at first it did not show up and i could not search for middlenames. Tested again today with a new person and it works:
http://hapi.fhir.org/baseR4/Person?middlename=Tirsdag&_pretty=true
I think that is pretty amazing!
Last updated: Apr 12 2022 at 19:14 UTC
