Stream: implementers
Topic: Sending multiple versions of a resource in a single Bundle
Stefan Lang (Feb 21 2019 at 14:36):
I'm looking at the following use case:
A source system with FHIR RESTful API shall export all data of a given scope (at the maximum: all resource instances it contains - ignore file sizes and splitting of data for the moment), including all prior versions of all instances. That, obviously, could easily be achieved using the history interaction.
Now I want to push all data I received from the source to a destination system, using the FHIR RESTful API as well.
My idea would be to transform the history Bundle I received to a transaction Bundle and throw it at the destination.
Nevertheless, there are references in the source data (say: a Condition instance references a Patient instance), so the destination needs to keep track of the original ids during import. So the "Update as create" mechanism ( http://hl7.org/fhir/http.html#upsert ) would also be necessary (which is defined for R4, but not for STU3). This implies every POST and PUT from the source would become a PUT in the transaction.
If I follow that concept and make up such a transaction Bundle, containing 2 Patient resources with the same id, but meta.versionId being 1 and 2 respectively, I get errors:
HAPI complains with "Transaction bundle contains multiple resources with ID: Patient/myId"
test.fhir.org says "Unknown message MSG_Transaction_DUPLICATE_ID (entry 2)".
This of course is true, but seems to kill my idea of how to replay a history to another server.
So, hopefully I overlooked something? Maybe there's also advice from FHIR Bulk Data that I didn't find?
Michele Mottini (Feb 21 2019 at 14:41):
Don't think there is a way to 'reply the history' to another server. It sort of runs counter the idea of versioning itself: it is managed internally by each server, not controlled / controllable from outside
Stefan Lang (Feb 21 2019 at 14:42):
The idea is: if I replay all actions, the destination will build a history that is equivalent to the one in the source system
John Moehrke (Feb 21 2019 at 15:00):
only if you also turn-back-time.... lastupdated.. I presume your definition of 'equivalent' is recognizing these kind of differences?
Stefan Lang (Feb 21 2019 at 15:04):
Well, lastupdated would be another problem to solve in this context. But for the timestamp I think there would be ways to sufficiently document the original timestamp (in the context of my use case)
Stefan Lang (Feb 21 2019 at 15:20):
The alternative, as far as I see, would be to simply use a collection (or maybe also transaction) Bundle and define a custom operation
John Moehrke (Feb 21 2019 at 15:20):
as soon as you start adding exceptions, you are not using standards... Yes you could define that lastupdated would be preferred in your use-case
Stefan Lang (Feb 21 2019 at 15:25):
The goal is to comply to the standard, which is why I'm asking. I thought more of like a "lastUpdatedInSource" extension or similar to handle that, which should be sufficient here.
But the duplicate id issue can't be solved this way.
Lloyd McKenzie (Feb 21 2019 at 15:42):
There is no way to "restore" a server that retains history right now. It's been discussed previously, though I'm not sure if we have a change request to add that yet. There's no way to do it using the HTTP actions defined so far.
Stefan Lang (Feb 21 2019 at 15:44):
Thanks Lloyd, that clarifies it in terms of the original idea.
So best practice for now would be profiling a Bundle (collection or transaction?) with an accompanying custom operation?
Lloyd McKenzie (Feb 21 2019 at 15:47):
Yes. An operation that takes a "history" Bundle would work.
Stefan Lang (Feb 21 2019 at 15:48):
Right, "history" might be even better - I just wasn't sure whether POSTing a history Bundle would throw an error in the very early stages of validation
Lloyd McKenzie (Feb 21 2019 at 15:52):
Operations can consume pretty much anything. No reason for it to throw an error.
Stefan Lang (Feb 21 2019 at 15:57):
Thanks again. That sounds like a way to go.
Grahame Grieve (Feb 21 2019 at 21:19):
it has been discussed but parked for now - it'll come up again in the bulk data import discussion
Brian Postlethwaite (Mar 02 2019 at 20:30):
My server implements this through a back door channel, as there is a lot of other information that is not in the resources, specifically around security context data, and some other internal stuff.
Last updated: Apr 12 2022 at 19:14 UTC
