We have a requirement to communicate using messaging as FHIR specifies.
We’ve used Bundle in which we’ve inserted a MessageHeader and then the resources we want to post via the API.
1- Does a bundle store as many resources as it contains on the desired backend resource store or just do create a resource of type Bundle ?
=> We’ve checked whether the resources were created using a GET all resources and we noticed the resources were not created as expected.
=> It only created a Bundle resource whose id is inserted in the response.
2- Is there FHIR implementation for messaging to check
3- We noticed there is a propertie called “signature” at the bottom of the Bundle.
=> Could you explain in which cases it is used ?
First, messaging is not the typical way information is shared using FHIR, it’s for very specific (and limited) use-cases that can’t be handled using other means. If you’re just looking to create resources, take a look at the ‘transaction’ and ‘batch’ capabilities of REST.
Second, there are no ‘standard’ messages defined by FHIR. If you’re going to use messaging, you have to negotiate with your communication partner what the event codes will be, what the focal resources will be, what other resources will be packaged in the message Bundle and what the allowed responses are (including event, focus and resources for those too). As a result, there are no standard reference implementations for messaging.
If you want a message to be processed, you need to send it to the $process-message endpoint. Posting a message to the Bundle endpoint will just store the message - it won’t execute it. (And it’ll only get properly executed if you post it to a server that recognizes and supports your particular message event.
Bundle.signature is used if you want to sign a Bundle. This is most typically done for FHIR documents, but you could theoretically sign a message if that was desired.
I didn’t mention that the backend of our expected APIs will be a messaging system based on Publisher/Subscriber and/or topic architecture (supposed to be on AWS)
So, yes it is a very specific requirement since we want our APIs to act as interfaces to this messaging system. We’re aiming to push resources through APIs so that they will be created on multiple destination applications (i.e resources will be created on multiple systems of our ecosystem).
Because I’ve seen in “messaging” that a MessageHeader should used in the first entry in a Bundle…
So if a transaction or a bach do the same thing, I would consider them.
Our issue with Bundles, is that resources are not created in the backend resource endpoint like /Practitioner… We noticed that only a Bundle resource is created and got a logical id from the server in the bundle payload in the response.
Read up on transactions and batch in the REST page (http://hl7.org/fhir/http.html) And if you’re going to use messaging, you can’t post to the Bundle endpoint - and you shouldn’t expect it to work until the server you’re sending the message to has written custom code to process your specific style of message.
No, I’m not going to post to Bundle endpoint. The idea is to bundle my the message header and the resources (as required by FHIR) to my API whose the target endpoint is the messaging system which is not implemented yet.
Of course the backend messaging system should be able to process the posted messages. Does FHIR suggest anaything here ? But the most relevant thing at this stage is that our API is FHIR-standardised and the payloads respect FHIR specification so that it is easy to integrate with our internal as well as partners’ applications.
If your objective is to just have the target system create the specified resources, you’re unlikely to find any existing message specifications that support that - and you’ll run into lots of pushback from most implementers you ask to support that - because there’s a standard non-messaging approach - namely batch and transaction. While you can create messages to do functionality that is supported using standard REST capabilities, it’s bad practice because it makes interoperability harder and more expensive.
I’ve read on Transactions and Batch, and I understood that they are not used in messaging. So the my choice of Bundle was right…
Of course, as I’ve already mentioned, our messaging system that is going to be set up and implemented, should be able to process messages by delivering them to the subscriber applications (destinations)…
Bundle is used whenever you’re transmitting a bunch of resources at once - as a message, a collection, a batch, a transaction, a document, a query response, etc. In general, batch and transaction are preferred over messages because less negotiation/custom coding is needed.
Yes, I see that we set a type {collection, bundle, transaction, message, etc} … It is a bit tricky the word “use” So it is Bundle resource whose types may vary …
We have to notify our applications using messages… so we should set “message” as type…
If you have to notify your applications using messages, then hopefully the system you’re communicating with has defined a messaging specification for you to comply with. If not, I’d question why you have to use messages. You can’t get transactional or batch behavior out of a message because the Bundle.entry.request element isn’t permitted.
