Stream: australia
Topic: Location positional searching (and maybe parameterised searc
John Carter (Aug 16 2018 at 05:08):
In the AUPD Location profile (http://fhir.hl7.org.au/fhir/pd2018Mar/StructureDefinition-au-pd-location.html), we see contradictory location searching text, and we want to make sure which one is right for our implementation. The question is should it be
base/location?location.near[...]
or
base/location?near[...]
The text seems to have changed over versions of the profile. Here is how it reads in the March 2018 version and the snapshot build:
Search: Location Distance
Search based on address within a nominated distance.
GET [base]/Location?location.near=[latitude]:[longitude]&location.near-distance=[prefix][value]|[units-system]|[units]
Example: GET [base]/Location?near=-83.694810:42.256500&near-distance=le10.0|http://unitsofmeasure.org|km
The guidance on the base location resource (http://hl7.org/fhir/location.html#positional) looks like the second construction is correct.
Maybe more generally, how can I understand the pattern for when to prepend the resource name in a query? I'm mostly learning by example but haven't found or figured out the general rule.
Brian Postlethwaite (Aug 16 2018 at 05:41):
This is a great question John. and I'm wondering what we should do here.
PA (international) has just published the R4 format for this search, and is much better than the STU3 version, in that it can also work across joins too.
http://build.fhir.org/location.html#positional
And the VhDir profile is also considering adding in a definition for the contains search parameter that goes along with the new boundary extension format
http://build.fhir.org/extension-location-boundary-geojson.html
Brian Postlethwaite (Aug 16 2018 at 05:42):
Given where we are in the Australian implementations, I don't think it would be too much to actually adopt the new formats for our STU3 implementations if we had support from the other vendors in the space.
(I'd be happy to do it in ours)
Brian Postlethwaite (Aug 16 2018 at 05:43):
(The old format isn't the most pleasant thing, the new one I think is much nicer)
Brian Postlethwaite (Aug 16 2018 at 05:45):
@Brett Esler thoughts?
Brian Postlethwaite (Aug 16 2018 at 05:47):
The format from STU3 was (http://hl7.org/fhir/location.html#positional)
GET [base]/Location?near=-83.694810:42.256500&near-distance=11.20||km
don't know where that prefix came from.
Brett Esler (Aug 16 2018 at 11:21):
yes that 'location.' should not be there on either argument - i'll get that fixed
I would be happy to use the R4 format and change the spec; but we had better get a show of hands on a call
Brian Postlethwaite (Aug 17 2018 at 00:08):
Most definitely, as essentially that wouldn't be true STU3 compliance. But would make the transition to R4 easier down the track, since no-one else apart from the Telstra Health server has implemented it in this jurisdication that I know of.
John Carter (Aug 17 2018 at 00:57):
Thanks for the replies, we will immediately make sure that we're doing it without the extra 'location.'
We have a customer request for the combined search on location, so the R4 approach solves a specific problem for us, and we'd be in favor of pushing on to that as soon as practical.
Brian Postlethwaite (Aug 17 2018 at 01:07):
Actually, thinking of the implementation in our server, could quite happily support both syntaxes, as while parsing, can detect which form is being provided. So I really don't have any objections now.
Just need to get the proposal past all those in the AU implementer group.
Last updated: Apr 12 2022 at 19:14 UTC
