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

the subscriptions backport should describe how to do notifications in R4 as well as or instead of R4B

XMLWordPrintableJSON

    • Icon: Change Request Change Request
    • Resolution: Persuasive with Modification
    • Icon: Medium Medium
    • FHIR R5 Subscriptions Backport (FHIR)
    • current
    • FHIR Infrastructure
    • Specification
    • Hide

      Version 1.1.0 already includes notifications in FHIR R4.

      Mod:
      Add a section showing how to represent a SubscriptionTopic as a Basic resource in FHIR R4.

      Show
      Version 1.1.0 already includes notifications in FHIR R4. Mod: Add a section showing how to represent a SubscriptionTopic as a Basic resource in FHIR R4.
    • Gino Canessa / Oliver Egger: 12-0-0
    • Enhancement
    • Non-substantive

      The IG describes how to manage subscription topics using an R4B interface, and how to send notifications using an R4 bundle, but the first resource in the R4B bundle is a subscription status resource. This means that in practice, the notifications are also R4B. However for both technical and policy reasons, I believe that implementers will want to send notifications using pure R4 (even if the subscription topic interface is R4B). To do this, the subscriptionstatus resource would be replaced with a parameters resource with the same kind of values as the subscription status resource.

      This way, the notifications would be R4 and not raise any version issues for people who are implementing an otherwise R4 interface (the notion is that the subscription topic interface would run on a different end point that's R4B, and this is inherently more separable from the R4 core of the rest)

            ginocanessa Gino Canessa
            GrahameGrieve Grahame Grieve
            Watchers:
            2 Start watching this issue

              Created:
              Updated:
              Resolved: