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?
• 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 subst :id or subst {} or subst <> to just define the subst for the socket

(**What does "subst" mean?**)

Web socket protocol: rather than bare keywords like "ping", we should define JSON messages, which are objects with a "type" property. This will let us build a richer protocol later. E.g.

   {"action": "subscribeWhileThisSocketStaysOpen", "subscription": {Subscription Resource>}
   {"action": "listenOnAnExistingSubscription", "subscriptionId": <id>}