Stream: subscriptions
Topic: R5 Feedback
Gino Canessa (Nov 10 2020 at 20:47):
Hey all, I just finished a pass of updates on the R5 spec and was hoping to get some feedback. This pass was going through all the open Jira issues. Right now, the changes are all on http://build.fhir.org/branches/argonaut-subscription/ , with links below relevant to each issue. I did just notice that I missed one issue (FHIR#28490) so will add a pass of that when I have some feedback.
Specifically, I would like feedback on the field changes (e.g., Subscription.notificationUrlLocation, Subscription.maxCount, and changes to SubscriptionTopic.resourceTrigger & resourceType), the documentation on the channel types, and the two new operations (Subscription/$status and Subscription/$get-ws-binding-token).
Thanks in advance!
Gino Canessa (Nov 18 2020 at 13:45):
Just posting an updated table since this has been merged.
| Issue | Description | Resolution Link |
|---|---|---|
| FHIR#29315 | Define max entries to be sent in a subscription | http://build.fhir.org/subscription-definitions.html\#Subscription.maxCount |
| FHIR#28594 | Change the way resourceTypes are referenced | http://build.fhir.org/subscriptiontopic-definitions.html\#SubscriptionTopic.resourceTrigger.resourceType |
| FHIR#28498 | Explicitly call out that duplication notifications are possible for Subscriptions | http://build.fhir.org/subscriptions.html\#overview-notificationNote: missed listing this in current commit messages |
| FHIR#28491 | Reference from Subscription to SubscriptionTopic should be canonical | http://build.fhir.org/subscription-definitions.html\#Subscription.topic |
| FHIR#27149 | We need a way to register know SubscriptionTopics | http://build.fhir.org/subscriptions.html\#finding-topics |
| FHIR#27148 | Add prefer option for notification containing just url or request/response | http://build.fhir.org/subscription-definitions.html\#Subscription.notificationUrlLocationNote: not sure if listed in current commit messages |
| FHIR#27131 | Subscription should state that eventsSinceSubscriptionStart is inclusive of current notification | http://build.fhir.org/subscriptionstatus.html\#subscription-status |
| FHIR#27130 | Add operation on Subscription to get current status | http://build.fhir.org/subscription-operation-status.html |
| FHIR#27129 | Update Subscription and SubscriptionStatus harmonize client status checks | http://build.fhir.org/subscription.html http://build.fhir.org/subscriptionstatus.html |
| FHIR#26958 | Add a note to Bundle indicating that Subscription Notification bundles are non-normative | http://build.fhir.org/bundle.html\#subscription-notification |
| FHIR#25928 | Adding Subscription to "Exchanging Resources" section | http://build.fhir.org/subscriptions.html |
| FHIR#24448 | Update documentation to document what fields a client can and cannot update | Believe all the relevant fields have been removed from Subscription \(e.g., everything left has implementation-specific rules\). Need to check with Jenni if this feels correct to her. |
| FHIR#24350 | Topic.canFilterBy.matchType needs to be explicit what default behavior is | http://build.fhir.org/subscriptiontopic.html |
| FHIR#23859 | Create a new Bundle type for "subscription notification" | http://build.fhir.org/codesystem-bundle-type.html http://build.fhir.org/bundle.html\#subscription-notification |
| FHIR#23738 | Changes to Subscription to align with publish subscribe pattern using topic and filters | Question: not sure when this should be moved to next state |
| FHIR#22628 | websocket subscriptions should also support payload | http://build.fhir.org/subscription.html\#websockets |
| FHIR#21286 | Email delivery options should be more specific | http://build.fhir.org/subscription.html\#email |
| FHIR#21285 | Make lack of payload and re-query behavior ore visible | Covered by R5 redesign \(empty payloads\) |
| FHIR#20476 | Make Subscription.channel.type extensible | http://build.fhir.org/subscription-definitions.html\#Subscription.channelType |
| FHIR#19976 | Clarify Subscription notification limitations | Covered by R5 redesign \(servers advertise supported SubscriptionTopics\) |
| FHIR#19957 | POST vs Update operation texts | http://build.fhir.org/subscription.html\#rest-hook |
| FHIR#18994 | Subscription: section on security considerations | http://build.fhir.org/subscriptions.html\#safety |
| FHIR#18993 | Subscription and Subscriber-side security | http://build.fhir.org/subscriptions.html\#safety |
Brian Reinhold (Apr 21 2021 at 21:18):
@Gino Canessa I would just like to understand this new Subscription/$get-ws-binding-token. Is this something required to do a web sockets subscription? Is it mentioned in the capability statement? I could not follow the documentation on how to use it. A little explanation may get my thick head on the right track - thanks
Gino Canessa (Apr 21 2021 at 22:09):
Hi @Brian Reinhold , no worries. Since you are on an R5 thread, I will assume you are asking about that operation in R5. It is the same concept for the R4 backport, but some of the links are different.
For a general overview of using Websockets, there is a section on the subscription page. It has a flow-chart diagram that shows the whole workflow and a brief description of each step. It should provide some context for all of this.
That said, the $get-ws-binding-token operation is used to link together:
- An authenticated user session
- One or more subscriptions
- A websocket connection
The reason why these extra steps exist is due to the first item in the list - websockets do not work with 'standard' REST security flows, and we still needed some way to validate a user connected via websockets. Additionally, there are times that a single connection should be used for more than one subscription, and times that it's necessary to renew the token without recreating the websocket connection.
But, we also can't do security design for implementations, so this was the mechanism we came up with.
Since the operation is 'standard REST', the server gets to apply all of its normal security procedures before that call is executed. The client system then uses that token over the websocket connection (via the bind-with-token: message) to let the websocket server know the same.
Does that help clarify?
Brian Reinhold (Apr 22 2021 at 08:29):
@Gino Canessa Actually I am trying to get an two-year old subscriptions program working again (R4) and I am using the publicly available HAPI FHIR R4 server. What did not exist at the time I wrote my code was the returning of the logical id instead of just a 'ping' (which I had begged to get because it would greatly simply my existing code) and another bonus - a Capability Statement with an extension for the websocket address.
However, when I got the websocket address in the extension, appended it to the base URL replacing the http with ws, it failed with a 404 error. So I went back to the subscription and saw this $get-ws-binding-token operation which I had never heard of before. Maybe it's the websocket equivalent of an oAuth token? In any case I did a search on this site and this thread was the only hit I got. What I was really wondering is if this operation is required, how to find out if it is required, and how to use it if it is required, and if that was the cause of the 404 error.
Gino Canessa (Apr 22 2021 at 12:38):
Ah, the R4 IG for this was just balloted, so I doubt support is there for it in HAPI yet.
Brian Reinhold (Apr 22 2021 at 19:37):
@Gino Canessa Well that's actually good for me - it means that this web socket token is not my problem!
Last updated: Apr 12 2022 at 19:14 UTC
