Stream: implementers
Topic: New List Operation $resource-history
Brian Postlethwaite (Feb 08 2018 at 02:22):
One of the things we've been struggling with is getting histories for a subset of resource instances.
Someone on a call today suggested could we introduce an operation on list e.g. List/42/$resource-history that will return the equivalent of the _history for each entry instance referenced in the list.
This could then be used along with a subscription resource, and now we have a way of getting changes to a subset of data handled.
We plan to use this for managing an internal "black book" of providers/organizations in a local system and sync the set with this.
Brian Postlethwaite (Feb 08 2018 at 02:28):
Each client will maintain a list resource representing their local cached content
Brian Postlethwaite (Feb 11 2018 at 20:54):
Think I'll implement this to see how it goes today
Grahame Grieve (Feb 12 2018 at 19:29):
i meant to comment about this.... I didn't follow this, and particularly the issue of things falling out of scope
Brian Postlethwaite (Feb 12 2018 at 23:05):
Not sure I get the falling out of scope you describe.
The list is a set of references, so just remove items from the list if you don't want to get changes from them.
Brian Postlethwaite (Feb 12 2018 at 23:05):
The list resource just contains the IDs of all the resources in my "black book of resources" that I care about updates to
Grahame Grieve (Feb 13 2018 at 09:17):
but if something is removed from the list, that you already have updates for.... do you no longer care about it? then it comes back into the list? you don't get updates for the time it wasn't in the list?
Grahame Grieve (Feb 13 2018 at 09:17):
but this would be better done with the _list parameter, not a new operation on List
Brian Postlethwaite (Feb 13 2018 at 09:19):
The owner of the list is responsible for maintaining it, so you only remove the item from the list if you no longer care to receive updates for it.
Brian Postlethwaite (Feb 13 2018 at 09:22):
Use case:
1. user does search for set of organizations
2. user selects some of them and saves them in their own internal system (may not be fhir)
3. user creates a list on the fhir server with this list of IDs
4. later the user asks if there have been updates to that list of resources
5. user updates own internal system with the changes
6. user no longer interested in a particular org, removes it from internal system
7. user removes the specific ID from the list
Brian Postlethwaite (Feb 13 2018 at 09:22):
Hope this makes more sense as to how I was thinking it could be used.
Server doesn't remove things from the list, the user does.
Grahame Grieve (Feb 13 2018 at 09:23):
and if they put it back in the list? there's no history for the time it wasn't in the list?
Grahame Grieve (Feb 13 2018 at 09:23):
and you should still look at _list
Brian Postlethwaite (Feb 13 2018 at 09:24):
if you put it back in the list, then I'd have expected that they would have grabbed it from a search to find it.
Brian Postlethwaite (Feb 13 2018 at 09:26):
why wouldn't there be a history for when it wasn't in the list?
Grahame Grieve (Feb 13 2018 at 09:27):
well, are you doing _since on the history? or just getting everything all the time?
Brian Postlethwaite (Feb 13 2018 at 09:27):
I'm just expecting this to be the same as the resource type history, filtering to the ID values in the list
Brian Postlethwaite (Feb 13 2018 at 09:28):
(and maybe across resource types, which would be a global history list - filtered to the list of IDs)
Brian Postlethwaite (Feb 13 2018 at 09:28):
yes, do want _since
Brian Postlethwaite (Feb 13 2018 at 09:30):
didn't we have a matching search param for _till? can't see it in the spec.
Grahame Grieve (Feb 13 2018 at 09:31):
no no one has ever asked for it.
Grahame Grieve (Feb 13 2018 at 09:33):
but if you're asking for _since since the last update, and something drops out of the list and then back in again, then there'll be a gap while it was out, since you don't fetch history during that gap. In fact, more generally, you won't get history for new things added to the list from before the last _since after they were addded
Brian Postlethwaite (Feb 13 2018 at 09:34):
How can it drop into the list then out, its an ID.
Brian Postlethwaite (Feb 13 2018 at 09:35):
Don't care about this history of the list resource itself.
Brian Postlethwaite (Feb 13 2018 at 09:38):
implementation = [base]/_history?_list=List/42
This could be another syntax for it (filter by resources identified in the selected list)
(not interested in the history of the list, just the current version-less references in the list)
Grahame Grieve (Feb 13 2018 at 10:06):
I'm going to try again one last time....
Grahame Grieve (Feb 13 2018 at 10:12):
I have resource X.
I add it to list 42.
I ask for history on everything in list 42 since Time T1.
(I won't get any older history on X)
I ask for history on everything in list 42 since T2
I take it out of the list
I ask for history on everything in list 42 since Time T3.
I ask for history on everything in list 42 since Time T4.
I add it to list 42.
I ask for history on everything in list 42 since Time T15
(I won't get any older history on X)
I ask for history on everything in list 42 since T2
So I have T1-T2 nnd T5 but not T3/4
Brian Postlethwaite (Feb 13 2018 at 11:10):
I write a blog post on it trying to explain through examples
Brian Postlethwaite (Feb 13 2018 at 11:45):
Consider this sequence of operations are called on a server
T1 PUT http://example.org/Patient/1 (v1) T2 PUT http://example.org/Patient/2 (v1) T3 PUT http://example.org/Patient/3 (v1) T4 PUT http://example.org/Patient/4 (v1) T5 DEL http://example.org/Patient/2 (v2) T6 PUT http://example.org/Patient/1 (v2) T7 PUT http://example.org/Patient/1 (v3) T8 DEL http://example.org/Patient/1 (v4)
Then if I have List/42 that contains Patient/1 and Patient/2
The results of the operation would be
GET http://example.org/List/42/$resource-history > T8 DEL http://example.org/Patient/1/_history/4 > T7 PUT http://example.org/Patient/1/_history/3 > T6 PUT http://example.org/Patient/1/_history/2 > T5 DEL http://example.org/Patient/2/_history/2 > T2 PUT http://example.org/Patient/2/_history/1 > T1 PUT http://example.org/Patient/1/_history/1
Then if I also include the _since option
GET http://example.org/List/42/$resource-history?_since=T6 > T8 DEL http://example.org/Patient/1/_history/4 > T7 PUT http://example.org/Patient/1/_history/3 > T6 PUT http://example.org/Patient/1/_history/2
Brian Postlethwaite (Feb 13 2018 at 11:46):
In this example, doesnt matter when the entries were added or removed from the list, this $resource-history isn't reflecting that.
Brian Postlethwaite (Feb 13 2018 at 11:58):
https://wordpress.com/post/brianpos.com/348
Grahame Grieve (Feb 13 2018 at 20:09):
I think you're saying that the back history doesn't matter. But it's the _since that's at issue - you don't get the current state of Patient/2
Brian Postlethwaite (Feb 13 2018 at 20:37):
It's the history of the resource, i thought the example does this, where patient/1 gets multiple value in the returned bundle
Brian Postlethwaite (Feb 13 2018 at 20:41):
You don't get the current patient/2 as it hadn't changed, so i don't want to know about it. I already have that value from a previous call. Same as using Patient/_history
Christiaan Knaap (Feb 14 2018 at 18:55):
+1 for ?_list=List/42 instead of $resource-history. I would not mind implementing other search parameters on _history either.
Brian Postlethwaite (Apr 25 2018 at 21:44):
Update on this one, I've put an experimental implementation of this in my server.
Its now just simply the _list=42 syntax on the regular _history operation
And it works a charm, and was super easy to implement
(in my case a simple join on the results to the references in the list)
A working example from my server:
http://sqlonfhir-stu3.azurewebsites.net/fhir/Patient/_history?_list=42
Grahame Grieve (Apr 25 2018 at 21:48):
what does this do again?
Brian Postlethwaite (Apr 25 2018 at 21:52):
Permits you to filter the resources coming through the _history
Brian Postlethwaite (Apr 25 2018 at 21:52):
We plan to use it for managing synchronising local addressbooks.
Brian Postlethwaite (Apr 25 2018 at 21:54):
User registers a List resource instance with references to all the resources that they have in their local addressbook (say 100 resources out of 100k).
Then can use the Practitioner/_history?_list=42 to be able to detect when changes happen to the resources I have cloned locally.
Brian Postlethwaite (Apr 25 2018 at 21:55):
Makes the volume of data processed much smaller on client, and server
Brian Postlethwaite (Apr 25 2018 at 21:56):
But with overhead of maintaining the List resource
Brian Postlethwaite (Apr 25 2018 at 22:00):
(Added tracker #16022)
Last updated: Apr 12 2022 at 19:14 UTC
