Skip to content

Instantly share code, notes, and snippets.

@jkiddo

jkiddo/FHIR.Subscription.md

Last active November 15, 2017 13:37
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save jkiddo/e773d033c245c2c4fdef6d35cbe1a75b to your computer and use it in GitHub Desktop.
Save jkiddo/e773d033c245c2c4fdef6d35cbe1a75b to your computer and use it in GitHub Desktop.
Download ZIP
FHIR Subscription resource 'stuff-worth-talking-about'
Raw
FHIR.Subscription.md
  • Returing all resources matching criteria upon creation of a subscription
    • Current situation is that the client is supposed to know the full state up front. If any change occurs between the client trying to figure out what the full state is and creating the subscription, that state change is lost. This is fixed by letting the server evaluate the criteria once the subscription is created - and then acting upon it.
  • Resources leaving the criteria
    • When resources leaves the criteria the client is not notified. This makes it pretty hard to base an implementation around a more event based approach where the server is supposed to notify the client about any changes that may occur. As long as resources leaving the criteria set is not part of the notifications clients will become stale pretty quickly.
  • Order and use of ETag for updates
    • The order of the updates is not described. If ETags are used by the notifying server, the client is able to detect if an update has gone missing one way or another. The use of order is currently not described when using Subscriptions. A global order might even be necessary pr. subscription if the client must be able to actually keep track of updates.
  • Responses from the client
    • Should a subscription automatically be marked as inactive when it starts issuing 4xx errors? Should a server retry on all 5xx errors? Should it be part of the spec? Currently it is very open i terms of interpretation.
  • Web sockets lacks support for including payload
    • The current description of web sockets does not mention the use of payloads. Is that intentional? Should it be mentioned as an option?
  • REST hooks are not great in firewall'ed environments
    • The REST hook design is far from optional in a firewalled environment. But that might just be a known issue.
@niquola
Copy link

niquola commented Nov 15, 2017

Let's escalate subscriptions to FHIR2FHIR replication problem, where current Subscriptions is just a subset and on other end we have batch integration (potentially big data) between FHIR based systems

@kevinmarks
Copy link

  • Websub is a w3c spec that has a similar use case, and defines ways to discover subscription endpoints as well as subscribe to them. Worth a look.
  • You're assuming that ETags are sequential version numbers - while that is a possible implementation, it's not an assumption to depend on.
  • hashing a canonical version of the resource is an approach worth looking at

@niquola
Copy link

niquola commented Nov 15, 2017

About ETAGs: most of real subscription/watch API's implementations just move ETAG/Version into query parameter

@niquola
Copy link

niquola commented Nov 15, 2017 •
edited

For example: https://kubernetes.io/docs/api-reference/v1.8/#watch or http://docs.aws.amazon.com/sns/latest/api/API_Subscribe.html

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment