Stream: CARIN IG for Blue Button®
Topic: Patient Access API Compliance:_count without paging
Caitlin Ryan (Sep 10 2021 at 19:26):
I am curious about a server's conformance to the Patient Access API and/or the C4BB IG, if the server supports count, but not paging.
FHIR says that if a server does not support paging, the value indicated by "_count=[value]" is the maximum number of results the server SHALL return.
Let's say I want to see all of my EOBs and since I know there are a lot, I want to see these 10 at a time. The request t this server:
GET [base]ExplanationOfBenefit?patient=3545&_count=10
would return a TOTAL of 10 EOBs. Is this compliant with the CMS Mandate? Shouldn't we provide the member/patient with all the EOBs they are requesting?
@Corey Spears @Pat Taylor
Michele Mottini (Sep 10 2021 at 19:38):
if the server supports count, but not paging.
That will be bad. Either support neither - and so return always the complete result set, or do support both.
Daniel Venton (Sep 10 2021 at 20:08):
Or perhaps the consumer could then narrow the scope of their query until the matching rows is < 10.
Corey Spears (Sep 14 2021 at 13:41):
The regulation does not get into that kind of detail and the CARIN IG is silent about paging and count. I would think that the minimum requirement would be for the server to be able to return all of the resources (be that through the server support for paging or the clients ability to narrow the search parameter enough to get results that fit within the server defined limit).
Michele Mottini (Sep 22 2021 at 17:49):
or the clients ability to narrow the search parameter enough to get results that fit within the server defined limit
That's the part that won't really work: client do a search, there is no paging -
1) how does it know that those are not all the values?
2) how does it know how to restrict the search criteria?
For (1) it can use total, but that is not a required element and it can even be incorrect, and for (2) there is really no solution
Michele Mottini (Sep 22 2021 at 17:50):
So either the server implements paging or it ignores _count and always return everything (that is OK spec-wise)
Daniel Venton (Sep 22 2021 at 18:17):
Per https://www.hl7.org/fhir/search.html#count
"Servers SHALL NOT return more resources than requested, even if they don't support paging, but may return less than the client requested. "
Michele Mottini (Sep 22 2021 at 21:13):
So that's out as well then, I misremembered
Josh Mandel (Sep 22 2021 at 21:38):
What problem are we trying to solve here? FHIR defines a pretty clear search API that handles large (and small) result sets by 1) letting the server paginate, and 2) letting the client cap the maximum number of "match" resources returned per page. Why would we not just use this?
Michele Mottini (Sep 22 2021 at 22:14):
Avoid writing code to support pagination I guess
Last updated: Apr 12 2022 at 19:14 UTC
