Stream: implementers
Topic: Sharing large List resources with search on _list
Michael Donnelly (Feb 02 2020 at 01:29):
I was talking earlier with @Grahame Grieve, @Jenni Syed, and @Brian Postlethwaite about what to do with List resources with many entries. Unlike a search, List doesn't have any way to page when there are too many entries for the server and/or client to handle easily. Grahame pointed out that you can use the _list search parameter (which is available to all resources). For example, if
[base]/List/015ea13f29034217a8d51e42e88a7724
would be unmanageably large, you could instead get
[base]/Patient?_list=015ea13f29034217a8d51e42e88a7724
There are some challenges with this approach.
- How does the client know it needs to do a search instead of just reading the List?
- How does the client know that the List in question is a list of Patients?
- What if the List contains more than one type of resource?
- The entries in a List are just references; how can you constrain the results of a _list search to not include unnecessary, additional data?
How does the client know it needs to do a search instead of just reading the List?
The server can return an OperationOutcome with an issue type of too-costly.
How does the client know that the List in question is a list of Patients?
See the next one - it's harder to solve than this one, and that solution handles both cases.
What if the List contains more than one type of resource?
Instead of searching on a specific resource
[base]/Patient?_list=015ea13f29034217a8d51e42e88a7724
we can use the _list parameter without a resource
[base]?_list=015ea13f29034217a8d51e42e88a7724
The entries in a List are just references; how can you constrain the results of a _list search to not include unnecessary, additional data?
The summary parameter looks good in theory, but none of its options returns the right set of data.
_summary=truewould return a whole bunch of stuff List wouldn't (e.g. gender, birthDate, and telecom for Patient)._summary=textwould be weird and also doesn't include the name
What do people think about another option which would include the identifier and whatever is used as the display in references to that Resource? Maybe _summary=reference, making the whole thing
[base]?_list=015ea13f29034217a8d51e42e88a7724&_summary=reference
Brian Postlethwaite (Feb 02 2020 at 01:33):
You could also use _elements=id,name (just as you noted with summary)
Michele Mottini (Feb 02 2020 at 01:34):
Michele Mottini (Feb 02 2020 at 01:35):
(we sort of already went through that and there is a proposal to have operations to page through lists and groups - that we actually implemented )
Brian Postlethwaite (Feb 02 2020 at 01:35):
I prototyped an implementation of updating/managing the list resource using an operation $apply-changes which takes a List resource of type changeset as the only parameter, and then makes the changes listed in the resource to the list.
e.g. PUT [base]/List/45/$apply-changes
Grahame Grieve (Feb 02 2020 at 01:43):
@Michael Donnelly this bit I didn't understand:
_summary=text would be weird and also doesn't include the name
Brian Postlethwaite (Feb 02 2020 at 01:45):
I think Michael is implying that text only includes mandatory fields and the narrative, hence patient.name isn't there for example
Michael Donnelly (Feb 02 2020 at 01:48):
Right @Brian Postlethwaite
Michael Donnelly (Feb 02 2020 at 02:08):
@Michele Mottini has a better memory than I do. Yes, we definitely already discussed this.
Michael Donnelly (Feb 02 2020 at 02:08):
Here's the tracker
Brian Postlethwaite (Feb 02 2020 at 02:13):
Patch is problematic to me as for deletions, don't you need to know the index to remove? And is version specific?
Michael Donnelly (Feb 02 2020 at 02:20):
The tracker says
To proceed, James A. will add to List and Group a resource-level operation $getPage and try this out at a future connectathon.
Did anything happen with this?
Michele Mottini (Feb 02 2020 at 02:38):
We (CareEvolution) did implement $getPage
Jenni Syed (Feb 02 2020 at 03:01):
@Brian Postlethwaite technically? Probably yes. For jsonPatch there's also a test operation, assuming you have something that would uniquely identify an entry (eg: patient id for patient list) - but you would have to be more lenient than expected and ignore the index... :)
Michael Donnelly (Feb 02 2020 at 03:23):
We (CareEvolution) did implement $getPage
Client or server?
Michele Mottini (Feb 02 2020 at 03:43):
Server
Grahame Grieve (Feb 02 2020 at 04:02):
ok but name is not in the List.item... so that's no different. Which was that the context was, I thought.
Michele Mottini (Feb 02 2020 at 04:24):
(the tracker suggest to use count and offset for the paging, but if you look at the Zulip conversation what was decided was to use next links like in search results paging - and that's what we implemented for Group - for List we still have the offset method but we are going to align that to use next links)
Michael Donnelly (Feb 02 2020 at 04:26):
Nice.
Grahame Grieve (Feb 02 2020 at 04:26):
well, I think it's simpler to just use the search API, as Michael and I discussed earlier .
Michael Donnelly (Feb 02 2020 at 04:27):
I think none of us were aware of that last fall. :(
Michael Donnelly (Feb 02 2020 at 04:27):
I don't have a strong opinion which way to use, so I'll leave it to people with stronger opinions to fight it out.
Michele Mottini (Feb 02 2020 at 04:32):
That does not work for groups, does it?
Grahame Grieve (Feb 02 2020 at 04:33):
for groups?
Michele Mottini (Feb 02 2020 at 04:37):
There is no way to do a search for all the members of a Group like there is for a List, is there it?
Lloyd McKenzie (Feb 02 2020 at 04:55):
The semantics of Group are "a set of subjects to be acted upon as a collective group". Is that's what's wanted here? (List lets you have any arbitrary collection for any purpose you like - and can't be an actor anywhere.)
Grahame Grieve (Feb 02 2020 at 05:17):
I thought we had defined _group just like _list, but apparently not
Lloyd McKenzie (Feb 02 2020 at 05:45):
Group was defined as a passive actor. List is not an actor at all.
Michael Donnelly (Feb 02 2020 at 06:05):
I thought we had defined _group just like _list, but apparently not
Any reason not to?
Grahame Grieve (Feb 02 2020 at 06:07):
not sure. group is more complicated
Last updated: Apr 12 2022 at 19:14 UTC
