FHIR Chat · adding Subscription to "Exchanging Resources" · fhir/infrastructure-wg

Stream: fhir/infrastructure-wg

Topic: adding Subscription to "Exchanging Resources"

---

Eric Haas (Feb 05 2020 at 01:48):

in this section on the doco page:

Screen-Shot-2020-02-05-at-12.37.15-pm.png

In INM today we talked about adding a section on Subscriptions/FHIRCast and comparing and contrasting between messaging and when to use which for each use case/when.

Would like more thoughts before making a tracker?

Eric Haas (Feb 05 2020 at 01:49):

this would help implementers to decide early what to do and possibly make rational choices

Michael Donnelly (Feb 05 2020 at 01:54):

Sounds like a good idea to me.

Ward Weistra (Feb 05 2020 at 04:22):

-deleted, Zulip glitch I assume-

Gino Canessa (Feb 05 2020 at 18:45):

I'm for it, I do have some text around Subscription/FHIRCast in the draft spec, but haven't received a similar request for messaging yet (unless I count this thread :-).

Anthony(Tony) Julian (Feb 07 2020 at 00:02):

Does it belong there, or on the super page: pasted image

Anthony(Tony) Julian (Feb 11 2020 at 16:34):

I will look at the text, and see if I can morph into the requested area.

Anthony(Tony) Julian (Feb 11 2020 at 16:41):

@Gino Canessa - tp which specific section of the draft spec are you referring?

Gino Canessa (Feb 11 2020 at 16:43):

The link I've posted above goes to the section "Relation to FHIRCast", which is as much content as I have so far. Happy to add more, but I don't have the knowledge of the other areas (e.g., FHIRCast and Messaging)

Anthony(Tony) Julian (Feb 11 2020 at 19:55):

The page http://hl7.org/fhir/2020Feb/exchange-module.html gives the high-level detail of Rest, Messages, Documents, Services, and Database/Persistent storage. The ask is for information on when it is appropriate to use which, possibly with the pros/cons. I suspect I will start something, and let folks throw darts at it.

Lloyd McKenzie (Feb 11 2020 at 22:25):

There's at least some guidance that should be relevant here: https://docs.google.com/document/d/1OHfFcJ-OZvC81OFOOFudmcG3Lg5Wrrwo4n0dA09z40o/edit

Eric Haas (Feb 12 2020 at 18:42):

This really is a teaser to the bigger question what can FHIR messaging do that REST + subscriptions can't do. We are getting hammered on this in the notifications IG and since that IG very closely and carefully follows the core specification, I think it is appropriate to answer some of these questions here.

John Moehrke (Feb 13 2020 at 20:20):

Subscription should be seen as supporting REST and also Messaging. It should not be bright-line separation into either / or.

Eric Haas (Feb 13 2020 at 20:59):

throwing Jenni under the bus... " I think most of the arguments I hear of subscription over message is more: Messaging feels like a way we "ported" V2 style communication into the FHIR world - in which case we aren't gaining much. We already have V2 capabilities that can be used if you want messaging style interaction :) Subscriptions is better for more web/restful common patterns that FHIR has been very successful with." Which begs the question "whither FHIR messaging?.." and I don't see a suitable non hand wavy answer.

Eric Haas (Feb 13 2020 at 21:00):

yet

John Moehrke (Feb 13 2020 at 21:10):

the web world is full of examples of push messaging... just because HL7 has history with messaging that has a sour taste because of v2, should not be used as an excuse to denigrate the concept of messaging.

Lloyd McKenzie (Feb 13 2020 at 21:56):

Messaging makes sense when you need routing and when query/polling isn't reasonable due to architectural or business/regulatory reasons. (In some cases, being pushed data isn't an issue, but going looking for data and pulling it isn't permitted/is frowned upon/incurs much greater administrative effort)

Lloyd McKenzie (Feb 13 2020 at 21:57):

REST tends to scale much better than messaging because messaging is purpose-specific while REST is generally purpose-agnostic.

Grahame Grieve (Feb 13 2020 at 21:57):

I'm finding this dsicussion confusing because it seems to me that it conflates to different things

Grahame Grieve (Feb 13 2020 at 21:58):

• how to decide what gets sent
• how to send what is being sent

Grahame Grieve (Feb 13 2020 at 21:58):

traditional messaging has answers to both these.

Grahame Grieve (Feb 13 2020 at 21:58):

subscription is about the first

Grahame Grieve (Feb 13 2020 at 21:58):

messaging is about the second

Grahame Grieve (Feb 13 2020 at 21:58):

no?

Lloyd McKenzie (Feb 13 2020 at 22:00):

Subscription is about 'when' and perhaps somewhat about 'what'. Messaging allows an elaborate definition of 'what'. And subscription covers only one of the use-cases for messaging.

Grahame Grieve (Feb 13 2020 at 22:05):

so what's at issue here?

Lloyd McKenzie (Feb 13 2020 at 23:10):

Why would messaging get used (as opposed to non-messaging subscription notifications + query for additional data if needed)

Grahame Grieve (Feb 13 2020 at 23:11):

why would messaging get used

for which bit?

Eric Haas (Feb 13 2020 at 23:11):

I think of Subscriptions as more than the how. It has the possibility of defining the what so in my mind there is lots of overlap on the what.

Grahame Grieve (Feb 13 2020 at 23:13):

I think Lloyd refers to 'what is sent' which is not that specified in Subscriptions. Though I think it's not that well specified in Messaging either. Though it appears to me that a subscription that results in a message that has a message definition at least appears to give you the sense of control over content. Though I suspect it's largely a fantasy in that case

Eric Haas (Feb 13 2020 at 23:13):

Lloyd McKenzie1:56 PM

... and when query/polling isn't reasonable due to architectural or business/regulatory reasons. (In some cases,

which means "when you are stuck messaging... not really a choice.

Eric Haas (Feb 13 2020 at 23:14):

We have discussed defining the content using graphs in the topic too. fantasy now maybe...

Eric Haas (Feb 13 2020 at 23:15):

I don't understand routing. why couldn't a subscription notification be routed?

Grahame Grieve (Feb 13 2020 at 23:19):

part of the message header is the things you need to make routing manageable. You can always route any push message (eg http proxies) but typically people mean interface engines, and message header includes things like intended destination endpoint and person that make this much more manageable

Vassil Peytchev (Feb 14 2020 at 03:59):

Actually, interface engines make it possible not to care what the intended destination point is - the rules in the engine determine where the message goes (including multiple destinations).
I general, I believe there is a need to start describing in more detail the different uses of messaging. Some thoughts in no particular order:

• There isn't a hard distinction between subscriptions and messaging, there is a spectrum.
• I think one of the issues with FHIR messaging is that it cannot fuel the "app economy" (if you sense a hint of sarcasm, you are not necessarily wrong).
• As far as I understand, currently the only safe assumption to make, when you receive a message, is that the resources within are ephemeral, and they should be thrown away. This, I believe, causes an architectural friction between the REST-based parts, and FHIR messaging.
• If we take the Da Vinci Alerts IG as an example, there are two ways to look at the purpose of a notification.
  • One is that the event described in the notification is recorded in the receiving system, and that is as far as it goes. If that is the case, then indeed, why not use an HL7 V2 ADT message, send it over HTTPS, and be done with it? I believe it is trivial for most existing engines to add an additional destination for hospital admits that they already manage anyway. If the recipient needs the data in FHIR format, the V2-to-FHIR project will likely lead to several transformation tools to be employed for this purpose.
  • The other purpose of a notification is to be the starting point of additional data exchange, e.g. queries from the recipient of the notification to the sender of the notification for additional information. If that's the case, FHIR messaging for the notification part doesn't give you what you want, because there is no guarantee that the information in the message is queryable. If the IG adds the stipulation that the resources in the message need to be accessible via REST by the recipient, only then you can be certain that the subsequent steps of the data exchange can occur. And if you go that far, then why go through the trouble of messaging, when subscription will work and scale better?

Maybe we need to use some of the workflow calls on this...

Grahame Grieve (Feb 14 2020 at 04:06):

interface engines make it possible not to care what the intended destination point is - the rules in the engine determine where the message goes (including multiple destinations)

This is only true for some uses of messaging. For others, you need the extra information so the interface engine can decide.

Grahame Grieve (Feb 14 2020 at 04:06):

the only safe assumption to make, when you receive a message, is that the resources within are ephemeral, and they should be thrown away.

Unless there is additional documentation that explains why you can

Gino Canessa (Feb 14 2020 at 18:18):

Grahame Grieve said:

I think Lloyd refers to 'what is sent' which is not that specified in Subscriptions. Though I think it's not that well specified in Messaging either. Though it appears to me that a subscription that results in a message that has a message definition at least appears to give you the sense of control over content. Though I suspect it's largely a fantasy in that case

A bit late to this party, but Subscriptions does define what is sent (e.g., MIME type, empty/id/resource, etc.). Due to feedback, the current version has been limited to a single resource, but it has been discussed to allow graphs, etc. (Primary concerns are around security - trying to evaluate a graph without a logged-in user)

Gino Canessa (Feb 14 2020 at 18:23):

I think of Subscriptions as:

• definition of topics
• definition of filters
• definition of channel
• client ability to request notifications on a topic, with filters
• notification being sent across channel
• ability to figure out something is wrong

I'm not as well-informed on messaging, but so far I've treated it as a channel available for use. Perhaps someone else can jump in with why that is or isn't appropriate.

Eric Haas (Feb 14 2020 at 23:56):

why couldn't the horribly named SubStatus serve the same function with re routing as MessageHeader then Subscription could use the same routing mechanism?

Eric Haas (Feb 15 2020 at 00:00):

So far we have use FHIR Messaging when you have no choice or for V2->FHIR.... ( partly being provocative but also need to point out that not all use cases are based on rationale analysis so these are still legit)

Gino Canessa (Feb 15 2020 at 00:28):

Eric Haas said:

why couldn't the horribly named SubStatus serve the same function with re routing as MessageHeader then Subscription could use the same routing mechanism?

Theoretically it could, since I haven't finished drafting it yet. However, that was not the purpose of the resource, so it would need to be discussed.

I will note that the name poll still has SubscriptionStatus as the leading name though.

Eric Haas (Feb 15 2020 at 01:05):

the crowd is not always wise :-)

Vassil Peytchev (Feb 15 2020 at 01:30):

So far we have use FHIR Messaging when you have no choice or for V2->FHIR.... ( partly being provocative but also need to point out that not all use cases are based on rationale analysis so these are still legit)

I think there is some variety behind "no choice" that is worth investigating and providing at least some guidance for IG authors.

On a related note, I am somewhat surprised that the MessageHeader resource is at FMM 4. It's the resource which is at the core of the whole messaging paradigm, and I feel like we are just now getting into that area.

Grahame Grieve (Feb 16 2020 at 10:03):

we are just now getting into that area.

In the US that is; other parties have more extensive experience. But I didn't realise it was at 4. 3 feels more appropriate

Grahame Grieve (Feb 16 2020 at 10:04):

@Gino Canessa have we had any discussion about using MessageHeader for what the new resource is proposed to do?

Gino Canessa (Feb 16 2020 at 16:43):

@Grahame Grieve, not yet. So far, the sum total was:

• a new resource to act as the first resource in the notification bundles
• move all the 'status' extensions off bundle.meta into that resource
• the name of the resource, by vote: SubscriptionStatus

After a cursory glance at MessageHeader my initial concerns are:

• we've already received feedback that the notifications are 'heavy', this would add more weight
• notifications are may go to non-FHIR server recipients, is this too complex?

On the other hand, I'm a big fan of only having one way of doing something.

Eric Haas (Feb 17 2020 at 19:44):

I guess I was waiting to pounce after the first version of SS was penned. I think the whole routing thing may be legit for sub status. Second the idea of a focus is akin to the topic On the other hand, making a hybrid MH + SS would have elements that would make no sense for one vs the other which might be more trouble than it is worth. ( Maybe a baby step to merging would be to call it 'SubscriptionHeader' ;-) )

Gino Canessa (Apr 23 2020 at 18:09):

Re: the original request for this topic (FHIR#25928): most of the content that would fit in documentation already exists on the Subscription page. Should:

• documentation have a header that points to Subscription
• Move applicable content from Subscription to documentation (and point from Subscription)
• something else?

Vassil Peytchev (Apr 23 2020 at 20:21):

I think there needs to be a page similar to Messaging, and both documentation and the subscription-relevant resources will point to it. Since it can't be called Subscription (that's the name of the resource), maybe call it SubscriptionFramework?

Eric Haas (Apr 23 2020 at 21:10):

@Vassil Peytchev FHIR-I already approved FHIR#25928 which addresses this.

Vassil Peytchev (Apr 23 2020 at 21:19):

I am having a hard time figuring out what exactly was approved in FHIR#25928. It just points to this Zulip topic. Is it any different from what I posted? Or is it just your way of telling me "just get on with making these changes happen" :grinning_face_with_smiling_eyes:

Gino Canessa (Apr 23 2020 at 21:43):

Yes, that is the Issue I was working through at the time (I'm reviewing every issue with the word 'subscription' in it right now). There's approval for adding "something" to the "Exchanging Resources" section - I posted the question while trying to figure out what that "something" should look like (the Jira page is decidedly thin on details).

Since there was only a resource page, it has both the general/conceptual and the specific/concrete details together. Splitting them will be somewhat non-trivial (separation of concerns, repeated info, etc.) and I wanted to make sure I was on the right track before starting.

I won't start that piece until tomorrow, so if there are other opinions I'd like to hear them. But I feel good in that Vassil's thoughts align with mine, so I'm happy to take a stab at it as is.

John Moehrke (Apr 24 2020 at 14:25):

FHIR-I is grossly behind at applying approved CR, and often the CR doesn't indicate what will be changed. This is very concerning governance problem.

Lloyd McKenzie (Apr 24 2020 at 14:47):

Volunteers to start applying stuff?

John Moehrke (Apr 24 2020 at 15:57):

note, that I was willing to apply some... but I looked at the jira ticket and can't tell what I should do. As you can see above in this thread.

Gino Canessa (Apr 24 2020 at 16:24):

I think if the ticket isn't clear, it makes sense to ask rather than doing nothing.

When tackling issues, I typically check in on Zulip before starting anyway, then ask for review after a cut is done.

Lloyd McKenzie (Apr 24 2020 at 17:10):

Also, feel free to cherry-pick and work on the ones where the change is straight-forward/clear. Every little bit helps...

---

Last updated: Apr 12 2022 at 19:14 UTC