Stream: implementers
Topic: Bundle Transaction
Shovan Roy (Oct 31 2019 at 02:31):
Hi All,
I've a question around Bundle Transaction. In our project we are using this mechanism to register a user. During Registration we re expecting the registration service to provide us details on Consent, Person, Patient and RelatedPerson as a part of one atomic transaction. This works well from a transaction point of view. However the server is struggling to figure out what is the purpose of the particular transaction and apply the associated business rule accordingly as Bundle Transaction mechanism can be used to perform action on any set of resources. At this moment, we couldn't find any way to inform the server about a 'type' of transaction using which the server can determine the business rules to be applied.
We thought of addressing this issue by creating a FHIR document (administrative) and put all the relevant resources inside of it and use a Composition.type to let the server know what to do. However with this approach, we would loose the option of classifying what type of action we want on each resource (POST/PUT/DELTE/GET)
Any suggestion will be very helpful. Looping in @Grahame Grieve @Lloyd McKenzie for any comment/suggestion
Lloyd McKenzie (Oct 31 2019 at 03:29):
There is no "type" of transaction - clients can send whatever creates/updates/deletes/queries they like in whatever combination they like. If you're limiting support to a specific set of operations on a specific set of resources to mirror a particular back-end function, then you're looking for an operation or messaging interface, not transaction.
Shovan Roy (Oct 31 2019 at 04:33):
Thanks @Lloyd McKenzie , I thought of using operations, However I guess operations doesn't allow me to specify if what kind of HTTP method (POST, PUT, GET, DELETE) I would like to use for a 'in' Resource
Lloyd McKenzie (Oct 31 2019 at 14:44):
That's not pre-determined by your back-end?
Lloyd McKenzie (Oct 31 2019 at 14:45):
Can you explain further what the limitations are for the back end?
Shovan Roy (Nov 01 2019 at 22:07):
Thanks @Lloyd McKenzie ,
After having several discussion with the dev team, it sounds like we can manage these rules using backend. However, the project is requesting to avoid custom operation as much as possible unless there is no other option. Considering this, I got a suggestion from the project to handle this use case using Fhir document. I mean a Fhir document for user registration activity where each section of the document will contain the relevant resources and applicable rules. Please let us your suggestion around it.
Lloyd McKenzie (Nov 01 2019 at 22:51):
A document that has custom behavior isn't going to be better than an operation. If you want to avoid custom operations, you need to avoid custom behavior on the back-end. The benefit of not doing custom things is that clients can interact with you in a generic way. If clients have to carefully tune what they're sending to get their interactions with your system to work, then "pretending" to be a transaction (or document, or anything else) isn't going to help much.
Shovan Roy (Nov 03 2019 at 22:06):
Thanks @Lloyd McKenzie for your suggestion. Much appreciated...
AbdulMalik Shakir (Nov 05 2019 at 02:33):
My first thought would be to include a Task resource in the bundle that would serve as a signal of the transactional context of the bundle. The expected behavior of the receiving server based upon transaction context would have to be pre-coordinated in a must-understand way.
Lloyd McKenzie (Nov 05 2019 at 04:52):
Knowing that a Bundle is a transaction is a question of indicating that in the Bundle.type - whether there's a Task in it or not is irrelevant @AbdulMalik Shakir . (Tasks can appear in all types of bundles). The type of Bundle you accept should be driven by what your back end can do. Generally, 'transaction' Bundles should only be accepted by servers that can process arbitrary RESTful actions - and can process a collection of them as a single unit of work. There's no need to support all resources, or even all operation types. However, if you support 'transaction', then you SHOULD be able to execute all of the operation-resource combinations that your CapabilityStatement declares, and you shouldn't depend on the Bundle containing an particular combination of resources or operations.
Last updated: Apr 12 2022 at 19:14 UTC
