Hi 👋 I have a question regarding a GraphQL query on Practitioner. I’m fetching a list of practitioners (pagination is already handled on my side), and for each practitioner I retrieve several fields, including the associated ServiceRequest resources. My goal is simply to get the total number of ServiceRequests per practitioner. The issue I’m running into is the following: if I set count to n on the ServiceRequest field and a practitioner has n + 50 ServiceRequests, the query only returns n items, and there’s no way to know the actual total (n + 50). Pagination works well at the Practitioner level, but the limitation here is on the nested resources (ServiceRequest) inside the GraphQL query. I’m already using a main GraphQL query and would like to avoid making an additional Medplum call just to retrieve the total number of ServiceRequests. 👉 What is the recommended approach in Medplum GraphQL for this use case? Is there a way to access the total count of related resources even when the returned list is limited? Thanks in advance for your help 🙏

Hi @Estelle ! Just to be clear, you want to get the number of associated ServiceRequest resources for a given practitioner (and don't need all of the ServiceRequests themselves?), and you also don't want to make a separate query for this information, correct?

Hi @Maddy ! Yes, exactly. The reason I’m trying to do this within the same GraphQL query is that I’m already fetching other practitioner-related data in that query, and I was hoping to avoid making an additional Medplum call just to compute this count.

@Estelle hm I see! Currently, there isn't a way to add that into the same GraphQL query, but I just put this PR up to change that. It is technically outside of the FHIR GraphQL spec, but it seems like a reasonable logical extension. I believe the test case in there should cover your case, feel free to track its progress! https://github.com/medplum/medplum/pull/8301/changes

Thanks for the clarification and for opening the PR! That makes sense, and the proposed extension definitely covers my use case. I’ll keep an eye on the PR and test it once it’s available. Thanks again — really appreciate the quick help!