Support for FHIR Subscription mechanism

[chgl]

Is your feature request related to a problem? Please describe. Currently, the server does not emit notifications based on any FHIR Subscription resources, instead using the static configuration in fhir-server-config.json.

Describe the solution you'd like Support for the FHIR Subscription mechanism.

This would allow for configuring notification endpoints dynamically. Additionally, individual endpoints could be configured based on FHIR Search criteria increasing the flexibility and possible use cases of notifications.

Describe alternatives you've considered It's always possible to use the existing notification system and apply any resource filtering in custom receivers.

[lmsurpre]

Thanks @chgl, did you happen to try our fhir-notification-websockets support? I think that one obeys the Subscription mechanism but we disable it by default due tenant-privacy concerns in multi-tenant deploys and significant limitations in multi-server environments. You are right that the kafka and nats notifiers are based solely on static config.

Its also worth noting that the Subscription mechanism in the FHIR spec is getting heavily reworked for R5 and so our current thinking is to let that shake out before updating this component.

[chgl]

I wasn't aware of the significant rework from R4 to R5 (just checked, looks very exciting 😄), makes sense to wait! For my particular use case I have an existing service which creates a basic webhook subscription, but reworking that for WebSockets shouldn't be too challenging. Thanks for the tip!

[jordanperrin]

Do I have to use the FHIRNotification package in order to have the websocket messages send? or can I just create the Subscriptions resource and the server itself will recognize the resource and send messages based on the Subscription resource, I thought just creating the Subscription resource would be sufficient to send messages over websockets based on the FHIR docs