Stream: implementers
Topic: Messaging and Subscriptions
Pranitha Sruthi (Sep 09 2017 at 05:35):
Hi all, when can we expect the implementation of the concept messaging and subscription on FHIR?
Grahame Grieve (Sep 09 2017 at 06:11):
expect what where?
Grahame Grieve (Sep 09 2017 at 06:12):
test.fhir.org rully supports subscriptions
Pranitha Sruthi (Sep 09 2017 at 06:16):
Which server supports messaging?
Grahame Grieve (Sep 09 2017 at 06:17):
well, that depends what you mean
Pranitha Sruthi (Sep 09 2017 at 06:21):
Which server supports the operation'$process-message'?
Grahame Grieve (Sep 09 2017 at 06:22):
Apparently not test.fhir.org. The problem is that each message has different and specific semantics for processing. It's not a generic thing.
Pranitha Sruthi (Sep 09 2017 at 12:29):
@Grahame Grieve When can we expect the server test.fhir.org to support messaging?
Pranitha Sruthi (Sep 09 2017 at 12:30):
Is there any other server which supports messaging?
Grahame Grieve (Sep 09 2017 at 12:31):
did you read what I wrote? What messaging would you like it to support?
Pranitha Sruthi (Sep 09 2017 at 12:43):
Some of the examples include 'transfer a patient', 'visit notification' etc.
Lloyd McKenzie (Sep 09 2017 at 17:38):
The problem with "support messaging" is that processing a message requires message-event-specific processing logic. It's not nearly as generic as the typical create/read/update interactions. Every messaging interaction needs to be coded separately. And, at the moment, very little messaging has been defined in the FHIR spec. The MessageDefinition allows you to define the structure for the inbound message, what responses are permitted and what those responses look like. But we don't have any internationally agreed instantiations of that right now. And even if we did, it would be a singificant amount of work for the reference servers to add support for each one. (On the other hand, Subscription is a generic construct - once you add support, you can handle pretty much any type of subscription.)
Lloyd McKenzie (Sep 09 2017 at 17:40):
One of the ramifications of this is that messaging is more typically used in "closed" communities where the details of the exchanges can be decided and locked down. REST and services tend to be used in more open communities where participants can just "plug in" without changing their software much.
Last updated: Apr 12 2022 at 19:14 UTC
