How to set pagination in HAPI Fhir

[phanin...@gmail.com]

Hi,

I am trying to implement pagination  behavior for Communication resource in backend. I am passing limit and offset as a parameters and using .count() method to pass the limit.

I am not sure which method do I need to pass the offset value.

Thanks,

Bhanu

[James Agnew]

Hi Bhanu,

FHIR does not have a way of specifying offset from the client request. (This is FHIR's rule, not a HAPI thing fwiw)

You can pass the limit with the count() method as you point out, but you then need to use the next page link (bundle.getPage("next")) to get the URL to the next page of results, and you can then use the client to load that URL.

Cheers,

James

--
You received this message because you are subscribed to the Google Groups "HAPI FHIR" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hapi-fhir+unsubscribe@googlegroups.com.
To post to this group, send email to hapi...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hapi-fhir/97f7b2d2-6880-4336-9a59-70299d6e720f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Juan Carlos Méndez]

You could try to Perform a search directly by URL like this:

String searchUrl = "http://localhost:9999/hapi-fhir-jpaserver-example/baseDstu3/Patient?_count=10&_getpagesoffset=5&_sort=birthdate&birthdate=ge1989-01-01";

Bundle response = client.search().byUrl(searchUrl).returnBundle(Bundle.class).execute();

But _getpagesoffset isn't allowed according to the  standard https://www.hl7.org/fhir/search.html

[granada Coder]

So I think the thing is... that YOUR server has to understand .. whatever query-string parameter you use....(if you use hapi, it is _getpagesoffset and I think if you use Vonk it is _skip or something like that.

so _count is "standard"...but the paging "pageNumber" query string variable name is "your thing".

Below I'm gonna use "pagingainteasy" to emphasize that as long as YOUR server understands it, its ok.  (which of course is a single word of Paging Aint Easy!) :)

So when you get a paged search result, you get these "relation" links.
So as long as you populate the url values (3 urls below with pagingainteasy values).....and YOUR server can handle it.......then you're ok.

Also see this SOF : https://stackoverflow.com/questions/44673396/fhir-page-number-support/44673840#44673840

And "Grahame Grieve" (aka "da man")....comment. I'll paste it here : "yes, left to the implementers. you have to step through the pages to get the link for the page –"

so in a nutshell, your return payload have to have url's populated for "self,next,previous"....but as long as YOUR server understands that URL and whatever querystring you happen to use...you are compliant.

Disclaimer:  I learn something new about FHIR everyday.  So I am mostly confident in what I am saying here.

{

"resourceType": "Bundle",

"id": "aaaaaaaa-82f4-4c7c-9008-9e48878c1e19",

"meta": {

"lastUpdated": "2000-12-25T08:18:31.299-04:00"

},

"type": "searchset",

"total": 1000,

"link": [

{

"relation": "self",

"url": "/myr4fhirserver/*/Patient/?_count=33&pagingainteasy=5"

},

{

"relation": "next",

"url": "/myr4fhirserver/*?_getpages=55988c6e-2d47-496a-bff7-e2209c012650&pagingainteasy=38&_count=33&_pretty=true&_bundletype=searchset"

},

{

"relation": "previous",

"url": "/myr4fhirserver/*?_getpages=55988c6e-2d47-496a-bff7-e2209c012650&pagingainteasy=0&_count=33&_pretty=true&_bundletype=searchset"

}

],

"entry": [

{

Philosophy.  Because of the the way the urls are...

You might have have to use "_count" either (???)

Maybe

&pagingainteasy=0&countdracula=33

would still be ok, as long as YOUR server understands countdracula and pagingainteasy query string parameters.

SIDE NOTE:

One reason I got confused is because

https://www.hl7.org/fhir/http.html#paging

For their example, they have "&page=3" (etc, etc) which makes it ~seem like there is a standard.

<Bundle xmlns="http://hl7.org/fhir"> <!-- snip metadata --> <!-- This Search url starts with base search, and adds the effective parameters, and additional parameters for search state. All searches SHALL return this value. In this case, the search continuation method is that the server maintains a state, with page references into the stateful list. --> <link> <relation value="self"> <url value="http://example.org/Patient?name=peter&stateid=23&page=3"/> </link> <!-- 4 links for navigation in the search. All of these are optional, but recommended --> <link> <relation value="first"/> <url value="http://example.org/Patient?name=peter&stateid=23&page=1"/> </link> <link> <relation value="previous"/> <url value="http://example.org/Patient?name=peter&stateid=23&page=2"/> </link> <link> <relation value="next"/> <url value="http://example.org/Patient?name=peter&stateid=23&page=4"/> </link> <link> <relation value="last"/> <url value="http://example.org/Patient?name=peter&stateid=23&page=26"/> </link> <!-- then the search results... --> </Bundle>

[James Agnew]

I just wanna say this is an excellent explanation, bravo!

--

You received this message because you are subscribed to the Google Groups "HAPI FHIR" group.

To unsubscribe from this group and stop receiving emails from it, send an email to hapi-fhir+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hapi-fhir/a6d453e4-af4b-4e48-91b4-5cca71806c4dn%40googlegroups.com.

[granada Coder]

Thanks Eagle Eye James!  #postSept2020HL7ConnectathonVi3tAfterParty 

Corrected sentences from my original post;

errant:

your return payload have to have url's populated for "self,next,previous 

corrected:

your return payload would have url's populated for "self,next,previous 

errant:

You might have have to use "_count" either (???) 

corrected: 

You might not have to use "_count" either (???) 

One day I'll learn to type:

I've also recently learned:
It's @OptionalParam , not @OperationParam ...

#typingAintEasyEither

 

[Patrick Palacin]

Sorry for hijacking the old thread, but I have a question related to it.

For me the next-attribute doesnt seem to work well. I used it to paginate through the results, but after loading 12k entries it is emtpy / not provided anymore (even though more than 900k exist matching the search parameters).

Is there any specific reason why it behaves like this? You can  see that behavior on the public test server, too.

[kalyan pamula]

I see the same issue. Were you able to fix it