FHIR Subscription Working Page

Notes from Thurs Q0 Atlanta 2015

• when content is sent as a response to a notification, it should be a bundle - this is for rest-hook, websockets, and messaging
  • Rationale: provide the same payload semantics across all channels
• payload is mandatory, since a bundle will always be sent
• the subscription id should be one of the links in the bundle (rel to be determined — e.g. "triggered-by-subscription")
• unless otherwise specified, the bundle will be empty
• specify a list of GET operations using the template syntax in the URLS as defined by cds-hook (find somewhere common to specify that)
• server puts a bundle entry in the bundle for each GET operation
• same approach to be used in cds-hook

Question:

• when you have a web socket subscription, should it queue up notifications while not connected?
  • James: I would expect that notifications queue up for all types of subscriptions (e.g. if rest hook can't connect, it'll keep trying periodically too) This seems like something that we should phrase as implementation advice though, instead of a requirement. Maybe it could even be a subscription option.
• should a websocket subscription auto-expire?

Answer:

• If you register a subscription on the REST interface, it doesn't expire, and it queues transactions
• if you create a subscription when you connect on the web socket, then it expirse as soon as the websocket is closed

Corollary:

• when you connect you can either bind :id or bind {} or bind <> to just define the subst for the socket

JSON on web-sockets

• instead of bind:, the content is a JSON object, one of these two:

{ "type" : "bind-subscription", "id" : "xxxx"}

same as bind: id

{ "type" : "create-subscription", "subscription" : { ... subscription resource ... }

This creates a subscription in the web socket which has no persistence once the socket is closed

Note for Grahame's server - until DSTU3(?), I support both bind: and the JSON syntax