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

Why does backport-notification-url-location exist?

    XMLWordPrintableJSON

Details

    • Icon: Change Request Change Request
    • Resolution: Persuasive
    • Icon: Highest Highest
    • FHIR R5 Subscriptions Backport (FHIR)
    • 0.1.0 [deprecated]
    • FHIR Infrastructure
    • Payload Types
    • Hide

      The request came up during Connectathon testing for R5, where there is a new bundle type that does not include the constraints of the history bundle.

      Given that the backport does not actually have the flexibility to make this necessary, the extension should be removed.

      Documentation should be updated to state that it is required in the entry.request and entry.response (per bundle requirements), and SHALL be present in entry.fullUrl as well.

      Show
      The request came up during Connectathon testing for R5, where there is a new bundle type that does not include the constraints of the history bundle. Given that the backport does not actually have the flexibility to make this necessary, the extension should be removed. Documentation should be updated to state that it is required in the entry.request and entry.response (per bundle requirements), and SHALL be present in entry.fullUrl as well.
    • Gino Canessa / Yunwei Wang : 10-0-0
    • Clarification
    • Compatible, substantive

    Description

      Why is it important to provide optionality between full-url vs request-response vs all in notification-url-location? Can you please just give implementers a single, workable path forward? Without any background on this extension, it feels like a crazy and unnecessary amount of twiddly configuration. (ValueSet: http://hl7.org/fhir/uv/subscriptions-backport/2021JAN/ValueSet-backport-notification-url-location-value-set.html#expansion). Also, what does it mean for payload to be id-only, but notification-url-location to be none? Again, I'm likely missing background, but it seems like this spec should merely require servers to always do "all" and that "none" is a bug in the spec that conflicts with the id-only payload.

      Existing Wording:

      Each Bundle\.entry for id-only notification SHALL contain a relevant resource URL in the fullUrl, request, and/or response elements\. The Subscription’s notificationUrlLocation element describes the behavior which should be used\.

      (Comment 23 - imported by: Gino Canessa)

      Attachments

        Activity

          People

            ginocanessa Gino Canessa
            Isaac.Vetter Isaac Vetter
            Watchers:
            1 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: