Stream: subscriptions
Topic: Publically available FHIR server supports subscriptions?
Brian Reinhold (Apr 21 2021 at 12:36):
I'm looking for a publicly available FHIR server that supports both transaction Bundles and Subscriptions (4+) and the Subscription support is 'activated'. I know this is an option for HAPI FHIR servers, but Subscriptions are not enabled out of the box so most such servers don't support subscriptions. The transaction Bundle contains Device, Patient, and Observation resources.
John Moehrke (Apr 21 2021 at 14:25):
there are many publicly available FHIR servers for testing https://confluence.hl7.org/display/FHIR/Public+Test+Servers
You can pull their capability statement and determine what they support.
Are you looking for support of the new subscription implementation guide backport for R4? I would hope the servers declare that support in their capability statement -- http://hl7.org/fhir/http.html#capabilities
Brian Reinhold (Apr 21 2021 at 14:45):
@John Moehrke That's a lot of servers to test. Was hoping to save myself a lot of time. Previously I have found it hard to find servers that are 4+, have subscriptions activated, and support transaction Bundles. I can support Subscriptions that just give the ping but I am really interested in those that give the logical id of the resource. That will GREATLY simplify the code!
Benjamin Langley (Apr 21 2021 at 18:55):
@John Moehrke somewhat of a side note - how does a server declare support for Subscriptions? The only thing I could find is the WS extension. If the server supports the Subscription resource is that declaring support? To know if it supports rest-hook notifications would you just need to create a new subscription and see if it is accepted?
John Moehrke (Apr 21 2021 at 19:17):
Clarification -- if one is speaking of the backport subscription, then one could find that declaration of support for the IG in the capability statement. Right?
https://build.fhir.org/ig/HL7/fhir-subscription-backport-ig/index.html
It seems they want you to query the $topic-list
https://build.fhir.org/ig/HL7/fhir-subscription-backport-ig/workflow.html
These would all be good comments to make on the ballot for this IG.
Benjamin Langley (Apr 21 2021 at 19:21):
Right that makes sense for the backport but I assumed 4+ plus meant regular old R4 subscriptions too. Is 4+ common abbreviation for R5 backport subscriptions?
John Moehrke (Apr 21 2021 at 19:26):
again.. good comment for the specification.
Gino Canessa (Apr 21 2021 at 19:48):
So far in R5 we have been using support for the resources as indicators for supporting subscriptions (e.g., if a server supports Subscription and SubscriptionTopic). There is some text on the subscriptons page, but if it either isn't clear or could use refinement, please file a ticket.
In the backport IG, there is a Conformance page, which links to the required capabilities (e.g., listing the IG as supported, operations, etc.). Same as above, if there is anything missing, confusing, or unclear please let us know.
Brian Reinhold (Apr 22 2021 at 14:00):
@Gino Canessa I have also assumed that support for Subscriptions was given by its presence in the Capability Statement. But as you stated that might not be the case as in HAPI FHIR - it might have to be enabled. Maybe that's an inconsistency?
John Moehrke (Apr 22 2021 at 14:33):
I would expect that subscriptions would be topic specific. Meaning that a use-case would drive for a use-case specific ImplementationGuide. Thus a server could declare support for that in their capabiltiyStatement. Thus clients also wanting to follow that ImplementationGuide would look for that decoration. This what IHE has defined for how these capabilities can be discovered. For example where we have defined a patient identity feed, that an app could subscribe to receive. Just one example, among an infinite future set of IGs.
Gino Canessa (Apr 22 2021 at 15:29):
John is correct - one of the big pushes for the redesign was that servers may only want to support some specific subscriptions, which this enables.
We still have an open discussion on whether servers need to communicate channel support in some conformance piece as well (e.g., a server may only support REST-hooks, etc.). So far, testing has shown that accepting/rejecting the subscription request is enough there.
Last updated: Apr 12 2022 at 19:14 UTC
