Stream: subscriptions
Topic: Publish Operation
Steve Atwood (Oct 14 2021 at 16:06):
Hi all, has there has been any discussion of a custom operation to publish events on a specific SubscriptionTopic? This is probably not relevant in a pure FHIR server, but I have a use case of a centralized FHIR facade that is backed by multiple independent services, some of which may be native FHIR while others are transformation layers on top of other data models. I need a way for those services to broadcast their events to the centralized facade which will then re-publish (possibly with some transformation/augmentation) to any external subscribers.
I was thinking the facade could support a "POST /SubscriptionTopic/{id}/$publish" operation that would accept a Bundle as the only input parameter. The idea would be that any producer services which natively support the new Subscription resource could just set up a rest-hook subscription to the relevant topic with my facade's $publish url as the target endpoint. Other producers would just make explicit REST calls to that endpoint at the appropriate trigger points in their application.
Any reason this would not work? Anyone else have a similar use case?
Josh Mandel (Oct 14 2021 at 16:29):
Neat, and worth thinking about! I don't see any immediate reason why this wouldn't work or why you could not incorporate this kind functionality into your implementation. Obviously driving to standardized view of exactly what the parameters and behaviors look like would take some experimentation and discussion, but it seems like a great (ahem!) topic area to me.
Gino Canessa (Oct 14 2021 at 17:39):
Interesting idea!
I think this could work without needing to use separate URLs during the POST (not that it can't, just that it shouldn't be needed). Since the notifications can contain the canonical URL of the SubscriptionTopic (and should if these are full-resource, which I assume these are based on the workflow), any notification received should be fairly straightforward to route.
I've been periodically considering what an 'accept a notification' operation would look like on a FHIR server, but it hasn't been pressing enough to bubble up. For discussion, I had been leaning towards something like base/$accept-subscription-notification, so that it could just be tied to the root server and and handling would happen from there. The same could also be said for adding an operation to /Bundle, in order to narrow the scope.
I don't want to discourage discussion on Zulip, but I'd also be happy to add this to the agenda for next week's call.
Steve Atwood (Oct 14 2021 at 19:29):
Cool, thanks for the responses Josh and Gino! I will plan to dial in next week so if there's time to discuss that sounds great. I know the focus is on getting the R4B stuff finalized for publication though so also totally fine if you want to defer this topic.
Gino, fair point about the SubscriptionTopic being potentially redundant. That said, some things I like about the topic-specific operation:
- (1) Separate routes just make it easier for monitoring/reporting on calls per topic using common logging/metrics/telemetry tools without needing to parse the post body.
- (2) Could optionally use custom scopes to control write access to specific topics.
- (3) The topic referenced in the notification could be different from the topic as defined by my server. The topic-specific operation allows that mapping to be expressed when I subscribe to your server. E.g. I could subscribe my "/SubscriptionTopic/Encounter.create/$publish" endpoint to your "/SubscriptionTopic/admission" topic instead of requiring business logic in code somewhere to do the mapping based on the canonical url in your notifications.
- (4) In the scenario where the producer is not a FHIR Subscription server, I might not need to require the SubscriptionStatus resource at all. Need to think through this case a bit more, but it's unclear to me if the SubscriptionStatus adds any value in that case and some of its required fields such as the Subscription reference become meaningless in that scenario, so if it's required they would have to insert some dummy reference.
To address your earlier question about the payload type for my specific use case, I think it could be either full-resource or id-only depending on the topic.
Last updated: Apr 12 2022 at 19:14 UTC
