Stream: implementers
Topic: result pagination - _count / offset?
Jose Costa Teixeira (Jan 16 2020 at 07:28):
How can we get only the 10th to 19th set of results in a search?
is there a _offset parameter?
René Spronk (Jan 16 2020 at 08:19):
No. In general, the size of the page can neither be fully defined by the client nor by the server. What's your use case?
Jose Costa Teixeira (Jan 16 2020 at 08:29):
if we use _count to get only a few results, how do we get the few next?
Jose Costa Teixeira (Jan 16 2020 at 08:30):
i don't want my mobile app to get all the results. Something like whatsapp
René Spronk (Jan 16 2020 at 08:39):
The result bundle contains <links>. The 'next' link is the URL to GET, which will return the next page.
Jose Costa Teixeira (Jan 16 2020 at 08:54):
thanks.
So I see this translates in _getpages, getpageoffset.. I was looking for these as part of the spec
Jose Costa Teixeira (Jan 16 2020 at 08:56):
Ok, that answers my question.
Side question: are these (_getpages, _getpageoffset) documented? should they?
René Spronk (Jan 16 2020 at 09:02):
Not as part of the FHIR spec. As part of HAPI perhaps.
Jose Costa Teixeira (Jan 16 2020 at 09:03):
I'll see where this is in Grahame's server, but i think _offset is a relatively standard way of working, we could adopt it
Lloyd McKenzie (Jan 16 2020 at 15:29):
We made a conscious decision in the spec to not support searching by offset - because some search technologies and architectural approaches have challenges doing that. The only search navigation mechanism supported right now is 'next', 'previous' and sometimes 'first' and 'last'.
James Agnew (Jan 16 2020 at 20:13):
FYIW _pages and _getpageoffset are just HAPI FHIR internal things that HAPI uses in its own paging links. They are intended to just be opaque parts of the next/prev URLs (which sure has not stopped people from figuring out how they work and directly modifying them. :) )
Lloyd McKenzie (Jan 16 2020 at 20:26):
Key thing is that if you changed your architecture or syntax tomorrow to not use those, you'd still be fully conformant
Jose Costa Teixeira (Jan 16 2020 at 21:44):
I thought that page or offset were standard options for pagination, next/previous not so much, but my experience is very limited.
Paul Church (Jan 16 2020 at 21:56):
One problem with page/offset is that if some resources are modified between the time you retrieve the first page and the second page, some results near the page boundary could be returned two or zero times. Having next/previous links makes this stable in the sense that when you look at the next page, it will always start from the same place regardless of changes to earlier pages.
Brian Postlethwaite (Jan 30 2020 at 09:07):
And the server might impose different page sizes if you try to define one bigger than it supports.
Milinda Perera (May 11 2021 at 11:34):
Hi Team,
We are exposing FHIR resources following facade pattern.
The implementation is stateless. To support "next", "previous" etc. we have to pass some information about offset in those URLs.
My question is, to support that, are there any restrictions (is it allowed) to introduce implementer specific (custom) query parameter?
Thanks,
Michele Mottini (May 11 2021 at 12:35):
Yes, you can use custom query parameters in the next / previous / first / last URLs. The clients will always just use those entire URLs, so they can contain anything
Milinda Perera (May 11 2021 at 14:49):
Thanks @Michele Mottini for confirmation
shuhaib k (Mar 24 2022 at 15:05):
We have been trying to add pagination functionality to my FHIR server. just want to check with you guys that any wrong doing below implementation or can you advise the better way to do it. Let's assume the client is requesting the below query http://localhost:80/Patient/ABC|123/DocumentReference to get the Documentrefrence bundle of the Patient( ABC|123), it might have n number of records in the backend system, so its big load for the server to serve the request as single bundle and also it's going to be a delay to get the response from the server. so we decided to implement pagination as below which will give you the first 20 records and the next link, next link will take you to another set of the 20 records and will give you the next page as page=3 for another 20 records.it keeps going until it reaches the last page. is it acceptable as per FHIR standard
**Note page size =20
**"link": [
{
"relation": "self",
"url": "http://localhost:5000/Patient/ABC|123/DocumentReference"
},
{
"relation": "next",
"url": "http://localhost:5000/Patient/ABC|123/DocumentReference?page=2"
}
],**
Josh Mandel (Mar 24 2022 at 15:07):
What you are describing sounds generally consistent with how FHIR pagination works. Do you have a specific question or do you want to share more details that you're unsure about? I will note that 20 seems like a very low cap; would think about 1000 or 100.
shuhaib k (Mar 24 2022 at 15:28):
@Josh Mandel: As per my understanding, the parameter name page is not part of the FHIR search parameter, I am afraid it is breaking the FHIR base standard if I use page parameter in URL on my system or I can use it since its part of the Rest API concept. I agreed 20 is the very low cap and we use 100, just for the describing whole story I mentioned some numbers with 20.
Josh Mandel (Mar 24 2022 at 15:30):
Ahh. The URL that you supply in your next (or prev) link is opaque from the perspective of the client. It does not need to look anything like a FHIR search URL, and indeed could be something like https://server.example.org/_fhir/continue/19758492838485859. The only requirement is that a client should be able to be reference this URL via HTTP get, and it should receive the next page of the search.
Josh Mandel (Mar 24 2022 at 15:31):
In general, it is probably a good practice not to embed parameter names like page= because you might find that clients try to get clever and directly manipulate those parameters. Conveying an opaque URL that simply acts as a continuation token is probably safer. On the other hand, maybe you want to support this kind of "under the abstraction barrier" client behavior for arbitrary jumps :-) These are your internal design choices to make.
John Silva (Mar 24 2022 at 17:48):
And when your FHIR server supports this it has to maintain state so that when the user (FHIR client) requests page=2 you know where to start from, i.e. that is unique to that FHIR client's search.
René Spronk (Mar 25 2022 at 06:48):
If using a server farm the use of page=2 is probably easier to deal with by a server.. if the continuation token is only known by one specific server which responded, the continuation queries may not be answerable by any other server.
shuhaib k (Mar 28 2022 at 13:34):
Thanks all for your suggestions. Really appreciated your prompt response on this @René Spronk: even I felt the same passing parameter value on page is much easier and easy implementation.
Last updated: Apr 12 2022 at 19:14 UTC
