1 of 21

FHIR Infrastructure Workgroup �ad-hoc call�Subscriptions & Messaging

​

March 4, 2020

2 of 21

Questions about Subscription Notifications

​

Q1. What is the content of a Subscription Notification? [closed]�

Q2. How to convey metadata Subscription id, event counts, etc? [open]

Prev discussion (Dev Days Amsterdam; Zulip):� Bundle with .entry[0] == SubscriptionStatus (new Resource)�

Q3. How does this relate to FHIR Messaging (if at all)? [open]�

3 of 21

Q1. What is the content for a Subscription Notification?

Core requirements� 6 data elements about the notification� Documented today in Bundle.meta extensions (yuck)

Ability to convey event-related resource IDs and content with the notification�

​

Future requirement� Ability to convey additional content (e.g., Graph of stuff)

​

​

4 of 21

Q2. How to express this content in FHIR?

Recap of possibilities…

  • Bundle with .meta.extension
  • Bundle with .entry[0] == SubscriptionStatus
  • Bundle with .entry[0] == MessageHeader

​

For concrete examples, see�https://github.com/argonautproject/subscriptions/tree/master/packaging-examples

5 of 21

Q2. How to express this content in FHIR?

Recommendation 1�Bundle with .entry[0] == SubscriptionStatus��Rationale

  • SubscriptionStatus is maturity 0 (or -1)
    • should evolve independently of MessageHeader (maturity 4)�
  • Notifications will be sent over many channels (email, WS, REST, messaging)
    • Source and event are already modeled in Subscription ID�
  • Keep the "payload" simple and consistent across channels

​

6 of 21

Q3. How does this relate to FHIR Messaging (if at all)?

Recommendation 2�Messaging is "just another channel" for Subscription Notifications� I.e., rest-hooks, web sockets, email, messaging, etc.�

Recommendation 3�For the messaging channel, we should wrap ‘subscription-notification’ bundles

    • Clearly delineates line between Messaging and Subscriptions
    • Subscription processing remains the same across all channels
    • Message processing remains the same for all message types
    • See idonly-mh-wrapped example here
    • Per discussion, see same example spliced here

​

7 of 21

Process-level concern: Conway's Law (each WG with its own sphere)

�

WG

Resources

FHIRI

Topic

CDS

EventDefinition, TriggerDefinition�

FHIRI

SubscriptionStatus and notifications

InM

MessageHeader, MessageDefinition

} What stuff can you listen for?

} How do we notify when stuff happens?

8 of 21

Questions? Discussion!

9 of 21

Feedback on Recommendations

Recommendation 1�Bundle with .entry[0] == SubscriptionStatus

Recommendation 2�Messaging is "just another channel" for Subscription Notifications� I.e., rest-hooks, web sockets, email, messaging, etc.

Recommendation 3�For the messaging channel, we should wrap ‘subscription-notification’ bundles

    • Clearly delineates line between Messaging and Subscriptions
    • Subscription processing remains the same across all channels
    • Message processing remains the same for all message types
    • See idonly-mh-wrapped example here
    • Per discussion, see same example spliced here

​

10 of 21

Topics for future calls? Issues include...

  • How to model trigger events
    • Text
    • Method criteria (e.g., ‘create’ on ‘Patient’)
    • Resource deltas using FHIR Search expressions
    • Resource deltas using FHIRpath expressions
    • ? Other�
  • How to model filters
    • FHIR Search expressions
    • ? FHIRpath expressions

11 of 21

How to package a Subscription notification

​

Notifications come with some basic context

Which Subscription? Which SubscriptionTopic? How many events? Errors?

​

… and some core content

What resources changed? How did they change?

12 of 21

Packaging Options (GH examples of each)

​

  • "Bare Bundles" with a stack of extensions (on Bundle.meta)
  • Bundles with a (new) SubscriptionStatus in .entry[0]
  • Bundles with an (enhanced) MessageHeader in .entry[0]
    • Nested under one property or flattened into ‘n’

13 of 21

Changes needed with MessageHeader

Need to add ~5 properties (subscription, topic, subscriptionStatus, eventsSinceSubscriptionStart, eventsInBundle)*

*Request for adding notificationType: handshake|heartbeat|event-notification

​

Need to relax prohibition on Bundle.entry.request, Bundle.entry.response

May need to relax the constraint that "Any resources referenced in the focus element are always included in the bundle" (if we use "focus" to point to the triggering subscription + topic)

14 of 21

Pros / Cons -- please add here :)

Bare Bundles

.entry[0] == MessageHeader

​

.entry[0] == SubscriptionStatus

  • In draft spec today
  • Messy use of extensions
  • We already decided against bare bundles
  • Align with messaging semantics (* ?!)
  • Re-use existing structures
  • Not a huge change
  • Unnecessary elements (eventCoding, source)
  • Confusion between "wrapper" events (the subscription triggered!) vs "underlying" events (an encounter started!)
  • Need to relax existing constraints (at FMM4+)
  • How many other use cases would also want to extend message header with their own properties?
  • Keeps notifications streamlined
  • Allow Subscription features to grow independently (maturity model)
  • Similar functionality → confusion about distinctions
  • Feels like a similar distinction between other bundle types (e.g., document - message - transaction - etc.).

15 of 21

Message Header Future

  • Add Subscription fields to message header.
  • R6: Add FHIRCast, CDS-Hooks, and Imaging fields to message header.

Is that where we want to be?

Bundle includes type, which dictates what entry[0] is

MH includes event, which dictates what fields are and what is intention

16 of 21

  • Bundle (read Bundle.type)
    • Bundle.entry[0]: Message Header (read event)
      • Subscription Fields
        • eventCount
        • topic
        • ...
      • CDS Fields
        • fhirUser
        • accessToken
        • ...
      • ResearchOpportunity Fields
        • …
      • FHIRCast Fields
        • ...

17 of 21

Relationship between Subscriptions & Messaging?

  • None
    • Never the twain shall meet
  • Messaging is a channel for Subscriptions
    • Wrap ‘subscription-notification’ bundles (example: here)
    • Splice the notification into the message (example: here)
    • Augment MessageHeader with subscription fields (example: nested, top-level)
  • Complete
    • Messaging is the content model for all notifications

18 of 21

Nothing needs to be said

  • Pros
    • We’re done! Let’s move on
      • Yunwei: Not true for FHIR-I (still need work around Messaging)
  • Cons
    • There is interest in using Messaging and Subscriptions
    • If people are going to do it [frequently], we should do something to help them
      • MD: Not necessarily true
    • At a minimum, some guidance documentation needs to exist (e.g., Relation to…)

19 of 21

Messaging as a Channel

  • Pros
    • Wrap: allows for same processing of notifications, regardless of channel
    • Splice: allows for better use of existing Messaging infrastructure (?)
  • Cons
    • Adds complexity to notifications
      • Wrap: Bundle containing: a message, containing: a notification bundle, containing data for an event that happened
      • Splice: requires different handling for REST notifications vs Message notifications
    • Confuses control
      • Is the destination pulled from the Subscription or the Message?
      • What protocol / channel is used for notification?
      • What is included?
        • Can you have an ‘empty’ subscription with a Graph in the Message?

20 of 21

MessageHeader Augmentation

  • Pros
    • One true way, for notifications at least
  • Cons
    • MessageHeader is FMM 4, Subscriptions are still being sorted out
    • Need to relax some constraints on bundle type
    • Adding fields to MessageHeader for each new case is not sustainable long-term
      • E.g., add fields for CDS-Hooks, FHIRCast, ResearchOpportunity, etc.
    • Defining Subscriptions becomes more complicated
      • Need to collect related definition items into Messaging artefacts

21 of 21

Recommendation

  • Messaging is a channel option for Subscriptions
  • Wrap ‘subscription-notification’ bundles
    • Clearly delineates line between Messaging and Subscriptions
    • Subscription processing remains the same across all channels
    • Message processing remains the same for all message types
  • ​