Total Record/count FHIR endpoint / List data pagination implementation approach

Projects FHIR
,
1

Team,

We have a requirement to paginate list data in the OHRI widgets / tables that display it. We are experimenting an implementation approach but this requires that we know the total count/number of records before hand in order to paginate. Looked around the FHIR documentation but can’t seem to see any endpoint that returns the total count of say the Encounter Resource given certain filter criteria.

Do we have any such endpoint? Secondly, any ideas on implementation approaches to paginate list data in the micro-frontends?

@samuel34 @ssmusoke @alaboso @eudson @vineeth68 @dkayiwa @ibacher

2

Is it fair to assume filter criteria are simple and are indexed in the database. Returning a total count for arbitrary criteria, complex filters, or criteria that include data that aren’t indexed would not perform well in existing systems that have hundreds of thousands or millions of encounters.

1 Like
3

Yes, all FHIR search endpoints return paginated list data. Probably, we haven’t done a good job documenting. Get more insights from the initial implementation here.

Things(GPs configuration) to take note of:

  1. Paging default - Sets the default page size
  2. Paging maximum - Sets the maximum page size

For example; A paginated list of vital data. From the first request, you will be able to know the total size of resources, and links (next & prev)

/ws/fhir2/R4/Observation?subject:Patient=f4d2d9e4-b6a4-426e-b6be-92a9b61faf8a&code=5090AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA,5089AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA,1343AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA&_summary=data&_sort=-date

Response;

{
   "resourceType":"Bundle",
   "id":"42416a13-e241-4f7e-ac4d-34853c5e4310",
   "meta":{
      "lastUpdated":"2022-05-20T07:45:13.145+00:00",
      "tag":[
         {
            "system":"http://terminology.hl7.org/CodeSystem/v3-ObservationValue",
            "code":"SUBSETTED",
            "display":"Resource encoded in summary mode"
         }
      ]
   },
   "type":"searchset",
   "total":44,
   "link":[
      {
         "relation":"self",
         "url":"http://openmrs:8080/openmrs/ws/fhir2/R4/Observation?_sort=-date&_summary=data&code=5090AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA%2C5089AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA%2C1343AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA&subject%3APatient=f4d2d9e4-b6a4-426e-b6be-92a9b61faf8a"
      },
      {
         "relation":"next",
         "url":"http://openmrs:8080/openmrs/ws/fhir2/R4?_getpages=2d1df6b7-f676-4551-95a5-f7ec3093ab99&_getpagesoffset=10&_count=10&_bundletype=searchset"
      }
   ],
   "entry":[
      //Omitted entries
   ]
}

Most of the microfrontend widgets don’t utilize backend paging.

1 Like
4

As a general principle, we haven’t documented things where we’re just conforming to the FHIR spec. As @corneliouzbett pointed out, there is a total element in all search bundles. While not strictly required by the spec, it is returned for all searches for OpenMRS. If you want to know just the total, you can run the query with ?_summary=count as noted in the FHIR search document.

By default, the FHIR2 API returns 10 results (this can be changed via the fhir2.paging.default). You can request more resources by using the _count=... search parameter (also documented in the FHIR search documentation) up to the value of the fhir2.paging.maximum global property (which defaults to 100).

This is a very important consideration and the FHIR2 search API can easily be abused to create a pathological query.

Strictly speaking, most frontend widgets are unaware that they are only using paged results and don’t properly handle things :slight_smile:.

1 Like
5

@ibacher @corneliouzbett noted with thanks