Stream: implementers
Topic: Messaging vs. Communication
Lloyd McKenzie (Aug 05 2019 at 22:17):
I've just submitted a new tracker item (GF#23061) seeking some clarification around the boundaries of using Messaging vs. using the Communication resource because the scope of Communication has been evolving to the point that there's now considerable overlap and I'm seeing projects that are starting to use Communication to essentially replicate v2 ADT messaging. Right now, there's no guidance that tells implementers or designers when to go one route or the other. I'm not sure exactly what the wording should be, but it's desperately needed and needs to be right.
@René Spronk @Paul Knapp @Bryn Rhodes @Grahame Grieve (and anyone else who wants to play :>)
Grahame Grieve (Aug 05 2019 at 22:20):
I'm not seeing the overlap
Lloyd McKenzie (Aug 05 2019 at 22:22):
Communication lets you identify a sender, recipient and reason and point to a payload that's being communicated. MessageHeader lets you do the same. Create a Bundle with either and post them to an operation endpoint that says "process this" and they're somewhat indistinguishable.
Paul Knapp (Aug 07 2019 at 16:48):
This discussion addresses notification and messaging so I think this is a topic for the INM work group.
Lloyd McKenzie (Aug 07 2019 at 16:51):
As owners of MessageHeader, they should certainly be involved in the discussion. As should PC (who owns Communication). Expect FHIR-I (responsible for the paradigms in general) and MnM (methodology) may have opinions too. This is probably the best place for a general discussion.
Grahame Grieve (Aug 07 2019 at 21:43):
sounds like we should have a quarter about this at Atlanta
Lloyd McKenzie (Aug 07 2019 at 22:11):
We have a joint scheduled w/ PC, but there's often a lot of other things on the agenda. We could do it the Tue Q2 session that InM hosts FHIR-I. @Michelle (Moseman) Miller, would PC be able to sent a rep? (Note that I won't be there - someone else would be representing FHIR-I.)
Michelle (Moseman) Miller (Aug 08 2019 at 13:22):
Tues Q2 might be challenging... What about using one of these other quarters?
- Mon Q4 - FHIR-I hosts a large joint Workflow quarter
- Tues Q1 (I can be available)
- Tues Q3 - PC hosts FHIR-I (and I can put this tracker on our agenda)
- Wed Q3 - PC hosted quarter (and I can put this tracker on our agenda)
Lloyd McKenzie (Aug 08 2019 at 18:53):
@Paul Knapp ?
Eric Haas (Aug 08 2019 at 23:18):
I am concerned we will burn a quarter with very little to show for it. I am curious what would be the specific goals of this quarter and would the outcomes provide any real benefit beyond what we already say about Messaging and RPC?
Besides Alerts who else chose to ignore messaging and use Communication + RPC route?
There is a lot of overlap in the content models but that doesn't seem to be the issue rather choosing the "right" paradigm, although what is right may be in the eye of the beholder, so( In the FHIR messaging section there is even a $process-message. operation for messaging so there is no real boundary here) My immediate thought is to create a master table to say "for transaction X consider paradigm Y ". Heck, that may already exist but the spec is getting so big even I don't know what's all in there.
Lloyd McKenzie (Aug 09 2019 at 00:50):
I think the objective would be specific wording for inclusion in the spec - wording that would differentiate the "business" level of asking for data and meeting that request from the "technical" level of routing information to relevant systems.
Eric Haas (Aug 09 2019 at 00:53):
So restating create a master table to say "for transaction X consider paradigm Y "
Lloyd McKenzie (Aug 09 2019 at 00:55):
More about language to insert in the "boundaries and relationships" section for both MessageHeader and Communication, and perhaps a blurb to inject in the 'messaging' page.
Eric Haas (Aug 09 2019 at 01:01):
I think this is too narrow a focus. It should be a start of a "how to in FHIR page". .... and ... For anything to get done in a quarter a straw man proposal ( table ) would be helpful.
Lloyd McKenzie (Aug 09 2019 at 01:52):
It's not necessarily wrong to have a page in the architecture section that does that too. But we can't count on people seeing/reading that. So the guidance needs to be everywhere that we can reasonably predict (in this case, based on experience) that designers/implementers might start barking up the wrong tree.
John Moehrke (Aug 09 2019 at 13:31):
I never considered that Messaging and Communication were so close, but now I see it... I expected Messaging would be used as is v2 messaging or subscriptions today for regular push of data. Where as communication is more one-off, uncommon, event, or human driven. No idea why I thought that except that I saw Communication more associated with (SMS messages, Email messages, etc), and messaging more backend business stuff.
Michelle (Moseman) Miller (Aug 22 2019 at 22:36):
Did we land on a work group meeting (WGM) quarter yet? Patient Care has another backlogged tracker (GF#13389) dealing with Communication scope that we'll try to squeeze into the same quarter as this boundaries discussion. My prior suggestions were:
Mon Q4 - FHIR-I hosts a large joint Workflow quarter
Tues Q1 (I can be available)
Tues Q3 - PC hosts FHIR-I (and I can put this tracker on our agenda)
Wed Q3 - PC hosted quarter (and I can put this tracker on our agenda)
Lloyd McKenzie (Aug 22 2019 at 22:40):
Pinging @Paul Knapp again
Paul Knapp (Aug 23 2019 at 04:59):
@Michelle (Moseman) Miller @Lloyd McKenzie I think this needs to include INM as its within their scope. Monday Q4 or Tuesday Q3 I think are best for me.
Lloyd McKenzie (Aug 23 2019 at 13:35):
Ok, let's plan for Mon Q4. I'm not sure we're going to have a whole lot of other things to discuss in that quarter and this should be somewhat juicy :)
Vassil Peytchev (Aug 23 2019 at 21:56):
I'd prefer Tuesday Q3, if possible...
Thomas Tveit Rosenlund (Aug 26 2019 at 06:05):
I never considered that Messaging and Communication were so close, but now I see it... I expected Messaging would be used as is v2 messaging or subscriptions today for regular push of data. Where as communication is more one-off, uncommon, event, or human driven. No idea why I thought that except that I saw Communication more associated with (SMS messages, Email messages, etc), and messaging more backend business stuff.
Should'nt Communication be more clearly documented to be what it was originally meant to be: "This resource is a record of a communication that has occurred. It does not represent the actual flow of communication".
Instead of redefining it to be another kind of MessageHeader? This could be solved by documenting the "record" purpose of the Communication resource at the very beginning of the Resource description. I don't think introducing a second MessageHeader flavor solves any issues, it just makes Messaging model more complex, and does not offer any obvious gains for that complexity. (other than the few projects using the Resource in a creative way?)
Eric Haas (Aug 26 2019 at 16:51):
I think that you can write all the words you want in the introductions, if if looks and act like a duck - folks are going to treat it like a duckl Structure works fine as a header the challenge is to convince folks its not a bundle header.
Lloyd McKenzie (Aug 27 2019 at 04:38):
@Michelle (Moseman) Miller is PC going to have much else on the joint PC/FHIR-I agenda for Tue Q3? I can make either work, so it's a question of the PC agenda for that quarter.
Thomas Tveit Rosenlund (Aug 27 2019 at 12:18):
I think that you can write all the words you want in the introductions, if if looks and act like a duck - folks are going to treat it like a duckl Structure works fine as a header the challenge is to convince folks its not a bundle header.
This happens time and time again in the FHIR spec, some resources are so similar that it is not trivial to determine what is the best choice for a specific use-case. The best approach is to change the resource in a way that it don't really fly as well for the overlapping use-cases. This might be difficult in some cases because of the requirements of theuse-cases you try to solve. I believe the best bet when you have overlapping Resource capabilities is to have good documentation that clearly states the boundaries and purpose of the resources, and I think this can get better as more implementations reveals overlaps in the spec, if the clarifications are documented that is.
Lloyd McKenzie (Aug 27 2019 at 14:31):
The challenge is that preventing abuse often prevents utility too. If we provide clear guidance about what not to do - and what to do instead, most implementers will follow it. (And those who choose not to can be clearly shown the error of their ways :>)
Michelle (Moseman) Miller (Aug 27 2019 at 15:56):
The agenda for Tues Q3 is flexible - just the usual FHIR admin + any trackers in the backlog. Stated another way, we should have plenty of time.
Last updated: Apr 12 2022 at 19:14 UTC
