FHIR Chat · Document Bundle - Transaction? · implementers

Stream: implementers

Topic: Document Bundle - Transaction?


view this post on Zulip Ardon Toonstra (Mar 21 2019 at 09:05):

For one of our use cases, we are specifying the exchange of FHIR Document (Bundle.type = document and with a Composition ect.). We are currently looking at the Bundle end-points for posting the Document Bundle ( http://hl7.org/fhir/documents.html#bundle ).

We are wondering if a post of a Document Bundle at the server's base URL should be seen as a transaction. Currently, at the given table in the link above the transaction is only mentioned in a ' e.g. a transaction'. Not very convincing. What's FHIR idea here?

view this post on Zulip Alexander Zautke (Mar 21 2019 at 10:16):

More details are given in http://hl7.org/fhir/http.html#other-bundles
So the idea is that the document bundle is decomposed into its individual resources, and for every resource either a POST or a PUT is executed depending whether or not the server already has a resource in its database with the corresponding id.

view this post on Zulip Alexander Zautke (Mar 21 2019 at 10:19):

For a document it is however not expected that all resources need to be accepted like in a transaction. At least that is my interpretation of it.

view this post on Zulip René Spronk (Mar 21 2019 at 10:33):

I don't think a server gets to pick and choose. IF a server decides to accept bundles being posted to /, the sever gets to determine whether a POST or a PUT is in order as a method. Other than that, all resources have to be processed. Client side orchestration, after all, this being REST.

view this post on Zulip Alexander Zautke (Mar 21 2019 at 10:38):

„if the identity of the resource refers to a valid location on the server, it should treat it as an update to that location“ sounds to me like it is being decided for each resource in the document bundle

view this post on Zulip Alexander Zautke (Mar 21 2019 at 10:41):

Of course all resources in the document bundle should be processed, yet, I don’t see the part where it is mentioned that for a document bundle all create or update interactions need to succeed.

view this post on Zulip Alexander Zautke (Mar 21 2019 at 10:44):

Though, I understand that such a behavior would be desirable, and needed in @Ardon Toonstra use case.

view this post on Zulip René Spronk (Mar 21 2019 at 10:45):

Agree - there is no 'transactional integrity'.

view this post on Zulip Alexander Henket (Mar 21 2019 at 13:43):

That's rather unsatisfying. Documents in CDA are regarded as 'whole'. Documents in FHIR apparently have a lesser status.

view this post on Zulip Alexander Henket (Mar 21 2019 at 13:44):

I.e. there's no guarantee that the server accepts the the whole thing this way.

view this post on Zulip Alexander Henket (Mar 21 2019 at 13:49):

Or maybe the server base URL is just unsuitable for documents and we should rather look into persistence at the Bundle endpoint

view this post on Zulip René Spronk (Mar 21 2019 at 14:51):

If you want to persist the Document as a whole: a) post it to /Bundle (instead of /), and it will be persisted as-is (as a bundle), b) if digital signatures etc. play a role, you need to persist a document as a Binary resource.

If you post a bundle (message, document, or any other non-transaction type) to / you're telling the sever that "for convenience reasons I'm grouping these resources, process them as if they were sent to you on a one-by-one basis", i.e. bundle is a transportation-level-batching mechanism.

view this post on Zulip Lloyd McKenzie (Mar 21 2019 at 16:15):

Generally, posting a document to the base endpoint would be treated as an error. A server could choose to treat it as a transaction, but the server would then have to decide whether to treat each resource as a create or update and figure out how to map the resource ids in the Bundle to its local records. Doing that isn't expected behavior though. A client wanting a document to be processed as a transaction should convert the Bundle to a transaction before posting.

view this post on Zulip Grahame Grieve (Mar 21 2019 at 23:24):

we say that a server is allowed to do that, and it's at the server's discretion how to handle the problems it creates


Last updated: Apr 12 2022 at 19:14 UTC