Stream: implementers
Topic: FHIR Messaging
Jayashree Surnar (Jul 07 2017 at 04:50):
hello all, how do we check whether any fhir server process the fhir messaging or not?
Jayashree Surnar (Jul 07 2017 at 04:55):
for example: i created a patient and send it to the server using fhir messaging (using our app) then fhir server should send a notificaation/message saying patient is created.how to do this? any ideas?
Thank you.
Lloyd McKenzie (Jul 07 2017 at 14:53):
Look at the CapabilityStatement for what's listed in the CapabilityStatement.messaging sectsion. Note that we don't have standard messages defined in FHIR yet, so some degree of site-to-site negotiation is going to be required.
Lloyd McKenzie (Jul 07 2017 at 14:53):
(Or an implementation guide will need to be defined that the relevant parties adhere to)
Jayashree Surnar (Jul 10 2017 at 04:17):
okay @Lloyd McKenzie .
sanjay sao (Jul 10 2017 at 20:01):
It looks like our company environment Test server which is based on JPA STU3, does not have CapabilityStatement.messaging section, which means subscription is not enabled or STU3 is not supporting it. What is the step to enable subscription resource for STU3 based JPA Server?
Ken Melms (Jul 10 2017 at 21:22):
Ok - we were about to begin looking into implementing a pilot using FHIR Messaging (Sync/async doesn't matter). I'm trying to figure out where to start. Been to a few connect-a-thons, but when it comes to what resources, example payloads, and figuring out the models I need to have in hand is getting a little confusing.
Ken Melms (Jul 10 2017 at 21:25):
Maybe use case first, then someone can opine?
I thought the workflow would be --
App -> EHR / IHE : Our app requests notifications of changes to patient (xxxx) (ADT events)
- ? Response is immediate, or am I asking for this to be queued up as "messages" and now I re-connect asking for answers?
App -> EHR / IHE : Our app requests anything new since (last check of events/messages)
Ken Melms (Jul 10 2017 at 21:25):
(Pretend the EHR/IHE is FHIR enabled)
Ken Melms (Jul 10 2017 at 21:29):
In other words: Do I ask the messaging based FHIR server to remember my requests and come back in later to retrieve, or do I have to ask it each time? I'm trying to figure out the basic model for ADT interaction information. If there's a test server I can look at live to see how this works, great!
Ken Melms (Jul 10 2017 at 21:29):
Applications claim conformance to one (or more) of the following exchange frameworks:
"RESTful FHIR": the RESTful API
"FHIR messaging": Message based exchange
"FHIR documents": Document based exchange
Ken Melms (Jul 10 2017 at 21:29):
http://test.fhir.org/r3/metadata - I don't see it here.
Ken Melms (Jul 10 2017 at 21:30):
http://fhirtest.uhn.ca/conformance?serverId=home_21&pretty=true&encoding=xml
Ken Melms (Jul 10 2017 at 21:30):
Or here
Lloyd McKenzie (Jul 10 2017 at 21:41):
Typically with messaging, you send messages and the receiver sends back messages. How those are delivered is outside the scope of FHIR. They could use the $process-message operation to do it pseudo-RESTfully. But you could also send them over MLLP like v2, wrap them in SOAP, post them to an MQSeries queue or any other delivery mechanism. A polling-based approach is also possible where messages get posted to a central store and then you query for the ones addressed to you and delete them from the central store once you've taken custody.
Jayashree Surnar (Jul 11 2017 at 03:59):
if i want to get patient's Past Medical History using fhir messaging, what are the steps i need to fallow? any suggesions please.
Thank you.
Jayashree Surnar (Jul 17 2017 at 04:54):
Hello everyon, can anyone suggest how to send a bundle using fhir messaging through postman/ARC?
Nick Hatt (Apr 11 2018 at 15:26):
Hi all, I'm interested in FHIR messaging and made a dedicated channel for it #fhir-messages. Hop on over and say hi so I can find some friends to test with. People in the #v2 to FHIR channel might be most interested, but this is more strictly about messaging than v2.
Grahame Grieve (Apr 11 2018 at 16:00):
@Richard Kavanagh
Dwight Walker (Apr 12 2018 at 01:42):
I would say lookup the person by surname and firstname and date of birth and perhaps medicare number. I don't know the syntax yet.
Aditya Joshi (Sep 05 2018 at 23:16):
Can we add Bundle.entry.request when Bundle.type="message"?
Wanted to use Resource update using PUT in Bundle.entry.request method, so that same resource don't get created again and again. This does work for Bundle.type="transaction". I am confused because specification states that Bundle.entry.request is only for some specific type of Bundles-
entry.request only for some types of bundles (expression : entry.request.empty() or type = 'batch' or type = 'transaction' or type = 'history', xpath: not(f:entry/f:request) or (f:type/@value = 'batch') or (f:type/@value = 'transaction') or (f:type/@value = 'history'))
If message exchange is not restful, I guess, entry.request is not needed but for restful implementation along with FHIR server (creating resources coming in message on server and updating them based on some business identifier) probably we need entry.request.
Could anyone please help with some guidance.
Lloyd McKenzie (Sep 05 2018 at 23:24):
If you're doing RESTful, then you don't have a message. In a message, you're essentially invoking an operation. The MessageHeader.event tells the receiving server everything it needs to know about what to do with the "focus" resources and everything connected to them. If you're wanting to send a server a transaction that tells it to create, update or delete specific resources, then the Bundle.type is "transaction" and you don't have a MessageHeader. You can't cross the streams :)
Simone Heckmann (Sep 06 2018 at 07:23):
Actually, just today I was thinking:
What if we want to combine the routability, server-decides-what-to-do-with-it semantics of the message bundle with the "this-is-what-happened" verbosity of the transaction?
Is it legitimate to have a message type Bundle who's focal resource is a transaction type Bundle?
Like: System a sends out a trigger-based message with an event like "change-notification" and the transaction-Bundle inside the message-Bundle lists the changes that occured. So when System B receives the message, it can look at the changes and decide based on it's own business logic if and how to process the changes.
Simone Heckmann (Sep 06 2018 at 07:24):
...that could be a generic approach to solve the problem discussed here: https://chat.fhir.org/#narrow/stream/112-fhir-messages/topic/Messaging.20as.20change-notification.20for.20IntegrationEngines
Lloyd McKenzie (Sep 06 2018 at 14:19):
If you've got a MessageHeader pointed to the transaction bundle, all sorts of magic is possible - that's the power of the MessageHeader.event (or an operation code) - the behavior is whatever you specify it to be.
Aditya Joshi (Sep 10 2018 at 13:26):
Hi. I am also going through similar process.
I am unable to understand how to use $process-message.
Specification states- "To send a message, a sender posts the message bundle to the /Bundle end-point, with a uri that identifies the receiver at MessageHeader.destination.endpoint."
POST http://fhir.hl7fundamentals.org/baseDstu3/$process-message?async=true
and in body, entire bundle of type=message. I have also added endpoint as baseDstu3 url, not sure if this is right way-
"destination": [
{
"endpoint": "http://fhir.hl7fundamentals.org/baseDstu3"
}
],
I am getting below error-
"There was an error connecting to http://fhir.hl7fundamentals.org/baseDstu3/$process-message?async=true"
I am missing some basic step here. I guess, /Bundle end-point.
http://build.fhir.org/messaging.html#rest
the above link states-
"To send a message, a sender posts the message bundle to the /Bundle end-point, with a uri that identifies the receiver at MessageHeader.destination.endpoint. The RESTful server accepts the bundle, stores it as a single bundle, and indexes it on the MessageHeader."
do i need to create my own endpoint and place it in MessageHeader.destination.endpoint? Could it be an endpoint of public fhir server?
Any example would be a great help.
Understanding $process-message operation -
Is it up to implementer to provide endpoint where to POST message and then invoke this operation. and what this operation will do is something implementer has to decide and write code. I mean it's all up to implementer. FHIR defines this operation just as a mechanism (something like abstract code) and implementer has to implement according to their business rule.
For example-
Sender sending EligibilityRequest message, it contains, EligibilityRequest resource, Patient resource (with patient id ) , Coverage Resource (with member id and plan id), Organization resource (Payer and Provider as Organization). Upon receiving this message, receiver will create EligibilityRequest resource (POST), update Patient resource (using Patient id) and if no such resource then create it (so first try PUT and then POST), create or update Coverage and Organization resources using their identifiers. It is essentially same process what Bundle.request.method do, is that right? In case of Bundle=transaction, we can specify what to do with each resource in request.method but in case of message, it has to be explicitly handled by receiver (pre defined code where it would be mentioned how to update or create resources). Is that understanding correct?
Aditya Joshi (Sep 10 2018 at 13:40):
Any Public FHIR server supporting Messaging and $process-message operation to test?
Aditya Joshi (Sep 10 2018 at 13:57):
MessageHeader.data element for invoking operations via messages
http://hl7.org/fhir/stu3/messaging.html#operations
The above link mentions using MessageHeader.data element but I cannot find data element in MessageHeader, am I missing something?
http://hl7.org/fhir/stu3/messageheader.html
René Spronk (Sep 10 2018 at 14:41):
Posting to /Bundle would archive the entire bundle as-is, without processing of its content. You really need a server capable of $process-message - AFAIK none of the test servers support this at this point in time. Remember that supporting the operation calls for a business-process layer behind that operation to create a meaningful response, which is the reason why a "test" server doesn't have such functionality.
Lloyd McKenzie (Sep 10 2018 at 14:45):
Right. In order to be able to process a message, a server needs to understand your specific MessageDefinition - what the event is, what the focus resource is, what to expect in the inbound Bundle, what the allowed responses are and - most importantly - all the business logic to go from input to output. None of that is standardized at the international level. (At least not yet, and so far not clear that there's interest in that ever happening as messaging seems to be more of a "closed environment" sort of thing.) The test servers only implement functionality that's standardized internationally.
Nick Hatt (Sep 10 2018 at 15:11):
@Aditya Joshi we have a test server that accepts the equivalent of ADT and Scheduling - you can see what they look like here: https://developer.redoxengine.com/data-models/PatientAdmin.html?showFhir=true. It requires a free signup to authenticate to the API.
As others have pointed out though, it looks like you want to do eligibility, and the endpoint we expose doesn't support that. You almost need the receiver to be built before you can become an eligibility client.
As for the MessageHeader.data issue, that does seem like something that needs to be addressed. It sounds like you want to want to use the RESTful API to invoke the $process-message operation, and section 3.4.6 covers invoking operations when you can't use the RESTful API for some reason. For example, you might use that logic to invoke a search or a FHIR operation over MLLP.
Last updated: Apr 12 2022 at 19:14 UTC
