Subscriptions R5 Backport
0.1.0 - ballot

This page is part of the Subscriptions R5 Backport (v0.1.0: STU 1 Ballot 1) based on FHIR R4. The current version which supercedes this version is 1.0.0. For a full list of available versions, see the Directory of published versions

Workflow

This section gives an overview of the workflow for both Servers and Clients to work with Subscriptions. Each channel MAY vary slightly from this general overview - specifically around interactions involving the Endpoint (e.g., when using a rest-hook the client must pre-configure an HTTP endpoint which the server validates, but when using websockets the client simply connects to the server).

Creating a Subscription

A workflow for creating a subscription is below:

Diagram showing a basic subscription workflow

  1. Server implements the core functionality required for subscriptions (see Conformance).
  2. Server implements one or more SubscriptionTopics. Topic implementation is specific to each defined topic, and will vary between implementations.
  3. Client asks the server for the list of supported SubscriptionTopics, via the Subscription/$topic-list operation.
  4. Server responds with a Canonical URLs Parameters resource.
  5. Client ensures that the endpoint is prepared (if applicable - see Channels).
  6. Client requests a Subscription (e.g., via POST, PUT, etc.).
  7. Server MAY accept the Subscription request (e.g., supported channel and payload).
  8. Server MAY reject the Subscription request (e.g., unsupported channel type).
  9. If applicable, the server MAY send a handshake to the endpoint.
  10. If the Server sends a handshake, the endpoint should respond appropriately.

Once the subscription is active, notifications will be sent according to the Channel. Note that error states may occur, see Handling Errors for more information.