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

Subscription.notificationEvent.eventNumber should be optional

    XMLWordPrintableJSON

Details

    • Icon: Change Request Change Request
    • Resolution: Persuasive with Modification
    • Icon: Highest Highest
    • FHIR Core (FHIR)
    • R5
    • FHIR Infrastructure
    • STU
    • SubscriptionStatus
    • Hide

      1. We will drop the sst-1 constraint as it's dependent on the type of subscription, and we don't want to do cross-resource constraints

      2. Need to revise other text to reflect different behavior for 'empty' notifications. Gino will propose wording.

      From Gino:

      Element changes (SubscriptionStatus.notificationEvent.eventNumber:

      • Short: Event Number
      • Definition: Either the sequential number of this event in this subscription context or a relative event number for this notification.
      • Comment: In subscriptions where delivery of notifications IS NOT guaranteed (e.g., REST-Hook), this number is a unique and monotonically-increasing event number for a subscription. In channels where delivery of notifications IS guaranteed, this number is a relative index for the events present in the notification (e.g., 1, 2, etc.).

      Note the the contents of the various tables in section 2.14.7 (Notification Types) need to be updated to include this guidance as well.

      Show
      1. We will drop the sst-1 constraint as it's dependent on the type of subscription, and we don't want to do cross-resource constraints 2. Need to revise other text to reflect different behavior for 'empty' notifications. Gino will propose wording. From Gino: Element changes ( SubscriptionStatus.notificationEvent.eventNumber : Short: Event Number Definition: Either the sequential number of this event in this subscription context or a relative event number for this notification. Comment: In subscriptions where delivery of notifications IS NOT guaranteed (e.g., REST-Hook), this number is a unique and monotonically-increasing event number for a subscription. In channels where delivery of notifications IS guaranteed, this number is a relative index for the events present in the notification (e.g., 1, 2, etc.). Note the the contents of the various tables in section 2.14.7 (Notification Types) need to be updated to include this guidance as well.
    • Gino Canessa/Yunwei Wang: 13-0-1
    • Enhancement
    • Compatible, substantive
    • R5

    Description

      Subscription.notificationEvent.eventNumber is only needed when providing reliable notifications. In the case this is not required/supported, this field can be ommitted.

      I suggest to make this field optional (or define a sentinel value that indicates it is not increased).

      Attachments

        Activity

          People

            ginocanessa Gino Canessa
            bvdh Bas van den Heuvel
            Bas van den Heuvel
            Watchers:
            2 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: