FHIR Chat · Search behaviour when sorting · implementers

Stream: implementers

Topic: Search behaviour when sorting


view this post on Zulip Richard Kavanagh (Jan 21 2021 at 18:11):

When performing a search it is possible to set the sort order using something along the lines of

/Patient?_sort=xxx,yyy,zzz

What is the expected behaviour if:

1) A search parameter is encountered that is not supported? - Is it just ignored by the server?
2) The number of search parameters provided exceeds those that the server supports?

view this post on Zulip Lloyd McKenzie (Jan 21 2021 at 18:24):

I don't think we've defined expected behavior. At minimum, the 'self' link should indicate what sorting actually happened.

view this post on Zulip Paul Church (Jan 21 2021 at 18:25):

I would think unsupported search parameters in a sort clause would be treated the same as in the search itself, potentially ignored unless strict handling has been specified.

view this post on Zulip Michele Mottini (Jan 21 2021 at 18:55):

You get 400s from our server

view this post on Zulip Josh Lamb (Jan 23 2021 at 19:59):

We ignore unrecognized params and do not support ordering. The ordering of data seems easier to implement client side (given number of data sources).

view this post on Zulip Lloyd McKenzie (Jan 23 2021 at 20:00):

Ordering on the client side only works if you bring down all of the data first, which doesn't work well if the set of data is large...

view this post on Zulip Josh Lamb (Jan 23 2021 at 20:03):

Thanks @Lloyd McKenzie, I am not sure of the use case here. But for claims data we added a last Updated param. We are hoping that consumers pull all data and then only pull for updates. The data can be quite large, as you say.

view this post on Zulip Lloyd McKenzie (Jan 23 2021 at 20:41):

If you have a light-weight client (e.g. a phone), you're not going to have any local persistence and will query data as you need it - and will generally query one page at a time - just what's needed to populate the current screen on the phone to ensure good performance and low memory use.

view this post on Zulip Lloyd McKenzie (Jan 23 2021 at 20:41):

Even apps that might be able to store more won't necessarily want to store everything, nor want to wait the length of time it would take for everything to be retrieved.

view this post on Zulip Josh Lamb (Jan 24 2021 at 00:15):

CommonHealth and Apple health only support local device storage. If you make an app on their stores you cannot run direct queries. When we asked the app devs they said they prefer local storage.

view this post on Zulip Lloyd McKenzie (Jan 24 2021 at 02:48):

If you're running a web app, you won't necessarily have any storage. And even if you do, you might not want to wade through 'all' of the patient's lab Observations. You want the most recent and the user will traverse back to older ones if/when they want them. With sort, you can do a quick call, get back 100 rows and display them. If you needed to bring back all of the rows before you could display the 'latest', you could be looking at several minutes time just to get the data over the wire.

view this post on Zulip Josh Lamb (Jan 24 2021 at 04:32):

Thanks @Lloyd McKenzie, great point regarding local storage. I imagine an EMR will have a wide variety of use cases. We are green with FHIR claims data so far and have not yet begin B2B use cases. If I developed a client app for claims data, I would not use local storage either.

view this post on Zulip Michele Mottini (Jan 24 2021 at 16:22):

Patient apps aggregate data from multiple source, they won't query & display. No sort is fine.


Last updated: Apr 12 2022 at 19:14 UTC