Uploaded image for project: 'FHIR Specification Feedback'
  1. FHIR Specification Feedback
  2. FHIR-43564

Subscription.status with handshake

    XMLWordPrintableJSON

Details

    • Icon: Change Request Change Request
    • Resolution: Persuasive with Modification
    • Icon: Medium Medium
    • FHIR R5 Subscriptions Backport (FHIR)
    • 1.2.0-ballot
    • FHIR Infrastructure
    • STU
    • Channels
    • Hide

      Related to FHIR-43563 - the subscriber knows that the subscription is becoming active because the handshake is received.

      Propose updating the workflows to clarify this and aligning with FHIR-43563.

      Show
      Related to FHIR-43563 - the subscriber knows that the subscription is becoming active because the handshake is received. Propose updating the workflows to clarify this and aligning with FHIR-43563 .
    • Clarification
    • Non-substantive

    Description

      In several of the interaction diagrams, creating a subscription with and without a handshake is described.  The diagrams include an arrow from the server to the client communicating the Subscription.status.

       

      For the non-handshake case, this is straightforward, the Subscription.create response just has the Subscription with status=active, or a reference to the Subscription with a status = active (depending on the prefer header.

       

      But when there is a handshake, how is the Subscription.status=accepted communicated to the client?  Does the client need to subscribe to their Subscription resource to know when it has been accepted? (kidding - that's turtles all the way down)  Or will the client just poll on their Subscription to see if it got accepted or rejected?  

      Attachments

        Activity

          People

            Unassigned Unassigned
            cooper.thompson Cooper Thompson
            Watchers:
            1 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: