Stream: fhir/infrastructure-wg
Topic: Message forbids entry.request and entry.response
John Moehrke (Feb 19 2020 at 22:28):
I have an urgent request from IHE to FHIR-I. We would like to understand why Messaging can't utalize the Bundle.entry.request and Bundle.entry.response? See #FHIR-26359
Eric Haas (Feb 19 2020 at 22:35):
@John Moehrke Why is it urgent? J#26359
John Moehrke (Feb 19 2020 at 22:37):
because we have an Implementation Guide that assumed we could use it, and that is going to EU Connectathon soon. So we need to 'hack' using alternative A vs B.. where A is create an extension that is just like .request and .response because we know that R5 will allow it, or B encapsulate a Batch transaction within our message.
Josh Mandel (Feb 19 2020 at 22:38):
Wait, how does your hacked extension actually embed resource content like Bundle.entry.response.outcome?
John Moehrke (Feb 19 2020 at 22:38):
extensions are an amazing thing
Grahame Grieve (Feb 19 2020 at 22:39):
why would messaging use .request and .response
Josh Mandel (Feb 19 2020 at 22:39):
Not _that_ amazing ;-) What extension type are you using? Or are you just stringifying the Bundle.entry.response.outcome?
John Moehrke (Feb 19 2020 at 22:39):
more specifically.. all we care about is .request.method with POST, PUT, DELETE
Josh Mandel (Feb 19 2020 at 22:39):
ahh
John Moehrke (Feb 19 2020 at 22:40):
we have a FHIR based equivilant to ADT...
Eric Haas (Feb 19 2020 at 22:40):
Why did you choose a message and not just a transaction bundle ? ( which version of subscription are you using?)
John Moehrke (Feb 19 2020 at 22:41):
because one can Subscribe to a message... you can't subscribe to a batch
John Moehrke (Feb 19 2020 at 22:41):
and messaging has nice functions for routing and source attribution
John Moehrke (Feb 19 2020 at 22:41):
messaging has its role in the world.
Eric Haas (Feb 19 2020 at 22:41):
which version Sub?
Josh Mandel (Feb 19 2020 at 22:42):
Do you have a link to the IG?
John Moehrke (Feb 19 2020 at 22:42):
I provided it in the Jira ticket
John Moehrke (Feb 19 2020 at 22:42):
NOTE: It is an IHE Profile, so it is not published using the HL7 IG publisher
Josh Mandel (Feb 19 2020 at 22:42):
Thanks! (https://wiki.ihe.net/index.php/Patient_Master_Identity_Registry_(PMIR))
John Moehrke (Feb 19 2020 at 22:43):
What si the reason to forbid this in a message?
Josh Mandel (Feb 19 2020 at 22:44):
R4 subscriptions, @Eric Haas .
John Moehrke (Feb 19 2020 at 22:44):
yes, we know that if we had been using IG Publisher, that we would have found this problem long ago by examples not validating... Yes.. we know.
Eric Haas (Feb 19 2020 at 22:48):
Where is a reference to the Batch behaviour trying to replicate ? ( assuming V2 chapter)
Eric Haas (Feb 19 2020 at 23:08):
What I don't understand is this
Messaging while needing to Create, Update, or Delete; like can be done in a Batch.
Its been a while for me, but in V2 isn't that all done with the event code? and wouldn't that be true for FHR using MessageHeader. event for each
Message Bundle in the Bundle of Bundle?
John Moehrke (Feb 19 2020 at 23:21):
Yes I hate the option of using the Batch Bundle enclosed within the Messaging Bundle.... but creative minds will do creative things
John Moehrke (Feb 19 2020 at 23:22):
Eric Haas said:
What I don't understand is this
Messaging while needing to Create, Update, or Delete; like can be done in a Batch.
Its been a while for me, but in V2 isn't that all done with the event code? and wouldn't that be true for FHR using MessageHeader. event for each
Message Bundle in the Bundle of Bundle?
a message only has one MessageHeader.event... we want to have one Message that contains creates, updates, and deletes... like a batch can
Lloyd McKenzie (Feb 19 2020 at 23:30):
My leaning would be for your message payload to be a transaction Bundle. Transaction semantics are not part of message and I'm not comfortable with the notion of trying to have messages use those structures directly.
Lloyd McKenzie (Feb 19 2020 at 23:31):
I.e. MessageHeader.focus would itself be a Bundle - which would be your transaction.
Lloyd McKenzie (Feb 19 2020 at 23:32):
That said, I'd be leery about introducing messaging unless you really have to. If you can come up with a RESTful solution, that's nearly always better and more interoperable.
John Moehrke (Feb 19 2020 at 23:32):
Lloyd McKenzie said:
I.e. MessageHeader.focus would itself be a Bundle - which would be your transaction.
Yes that is alternative B... (using Batch, not Transaction)
Lloyd McKenzie (Feb 19 2020 at 23:32):
Lots of systems will support 'transaction'. No-one supports your new custom message
John Moehrke (Feb 19 2020 at 23:33):
Lloyd McKenzie said:
Lots of systems will support 'transaction'. No-one supports your new custom message
The solution has plenty of ways for REST to be used... this is JUST a function for those that want to be notified
Eric Haas (Feb 19 2020 at 23:33):
a message only has one MessageHeader.event... we want to have one Message that contains creates, updates, and deletes... like a batch can
What about the MH.header focus 1..* MessageBundles?
Eric Haas (Feb 19 2020 at 23:34):
is that how you are trying to emulate Batching
Eric Haas (Feb 19 2020 at 23:35):
Anyway I mentioned Transaction too and generally agree with Lloyd :-)
Lloyd McKenzie (Feb 19 2020 at 23:37):
Being notified is quite different from processing a transaction
Lloyd McKenzie (Feb 19 2020 at 23:38):
If you receive a transaction, you're being told to make those changes on your system. If you're being notified, if anything, you'd want to transmit a copy of the transaction response - i.e. "here's what happened".
John Moehrke (Feb 19 2020 at 23:54):
In this case, yes you have agreed to follow the changes
John Moehrke (Feb 19 2020 at 23:54):
and it is a batch, so that you have the ability to ignore 0..* of the content without error
John Moehrke (Feb 19 2020 at 23:55):
I am still unclear on why this is forbidden in a message
Grahame Grieve (Feb 20 2020 at 00:07):
because 3 reasons:
- there's potentially very bad interplay between the message semantics, and the interaction semantics in request/response
- v2 messaging never had or needed anything like that
- no one has asked for it
John Moehrke (Feb 20 2020 at 01:41):
well, because no one has asked for it... is reason to FORBID? that seems extreme. We are now asking for it. Not just me but a group of people trying to create an Implementation Guide on patient identity management
Grahame Grieve (Feb 20 2020 at 01:43):
if that was the only reason, no.
John Moehrke (Feb 20 2020 at 01:43):
Unclear how the interpay problem is made better by a solution that puts the CUD actions in a enclosed Batch Bundle within the Message Bundle... How is that better? Can you explain the interplay problem? I don't see it
John Moehrke (Feb 20 2020 at 01:44):
I think v2 can do what we are trying to do...
John Moehrke (Feb 20 2020 at 01:44):
so.. am I completely non-persuasive? If so, then we will work up a solution with bundled bundles...
Grahame Grieve (Feb 20 2020 at 01:45):
lets say I took the typical content of a ADT_A01 message, and then inserted CUD instructions onto each of the segments... what would that mean? That would work at total cross purposes to the established purpose of the message
Grahame Grieve (Feb 20 2020 at 01:45):
I didn't say it was made better by a nested bundle, though it may help.
Grahame Grieve (Feb 20 2020 at 01:45):
how does v2 do it then?
Grahame Grieve (Feb 20 2020 at 01:46):
I've never see create/update/delete instructions in a v2 message. Not even master files
John Moehrke (Feb 20 2020 at 01:46):
well delete is not worth discussing... and ADT is always Update with a create if not found... right?
John Moehrke (Feb 20 2020 at 01:47):
I am looking for solutions. not looking for a fight
Grahame Grieve (Feb 20 2020 at 01:50):
delete is worth discussing ;-) My point is, the create/update/delete semantics are explicit in the definition of the event. Adding them explicitly would make a mess of the definition of the event.
Grahame Grieve (Feb 20 2020 at 01:51):
so if it can be done in v2, with out being explicit in the message, why is it necessary in FHIR?
Grahame Grieve (Feb 20 2020 at 01:51):
a possible response is: it probably is, but we're a long way down the path, and don't want to reset now.
Grahame Grieve (Feb 20 2020 at 01:51):
or: no, there's some reason why it can't be done without it.... and presumably can't be done with v2?
Lloyd McKenzie (Feb 20 2020 at 01:55):
I would be opposed to re-setting. The process for message handling has always been that you look at the event code. Throwing REST behaviors into the mix adds considerable complexity. There should also be a clear dividing line between REST vs. messaging behavior. Mixing the two is going to breed confusion. If you want to use message routing and have the purpose of the message be "Execute this REST batch", then a contained Bundle is a simple, clean way of structuring that. You've got the message and you've got the batch. You toss the contained batch to any RESTful engine and it knows what to do.
Lloyd McKenzie (Feb 20 2020 at 01:56):
As a side point, Batch is normative, so changing these invariants would be tricky at best.
Grahame Grieve (Feb 20 2020 at 01:56):
relaxing invariants is technically ok
John Moehrke (Feb 20 2020 at 01:57):
but the event code is sigular for the whole content of the message. I want to be able to mix some updates with some creates and some deletes
John Moehrke (Feb 20 2020 at 01:57):
I never asked for all of REST. Just create, update, and delete
Grahame Grieve (Feb 20 2020 at 01:57):
what i don't understand is how you know which resources are creates, updates, and deletes
Vassil Peytchev (Feb 20 2020 at 01:58):
Look at all the fun I miss when skipping the ITI committee meetings :-)
Here is how I understand the basic structure of the profile, and a possible solution:
- There is a subscription for patient-level events (add/update/merge/delete)
- The notification for the event is a message
Why can't the message event code relay the action to be taken on the patient?
Lloyd McKenzie (Feb 20 2020 at 01:58):
The equivalent of 'action codes' in v2 would be Task in FHIR. Having the message point at Tasks indicating what actions are to occur is a possibility if you don't want a contained Batch.
John Moehrke (Feb 20 2020 at 01:58):
the sender knows what has happened within their system, they are an authority
Grahame Grieve (Feb 20 2020 at 01:59):
ok so here's the clear difference: you know what happened in the source system. You cannot know what is the right thing to do in the destination system. The .request is an instruction to the destination system
John Moehrke (Feb 20 2020 at 02:00):
Vassil Peytchev said:
Look at all the fun I miss when skipping the ITI committee meetings :-)
Here is how I understand the basic structure of the profile, and a possible solution:
- There is a subscription for patient-level events (add/update/merge/delete)
- The notification for the event is a message
Why can't the message event code relay the action to be taken on the patient?
because the event is singular for the whole message and we want to include Creates, Updates, Merges, and Deletes within one message
Vassil Peytchev (Feb 20 2020 at 02:00):
Why do you want to mix them?
Grahame Grieve (Feb 20 2020 at 02:00):
technically, this is a message that includes a history bundle
John Moehrke (Feb 20 2020 at 02:00):
Grahame Grieve said:
ok so here's the clear difference: you know what happened in the source system. You cannot know what is the right thing to do in the destination system. The .request is an instruction to the destination system
yes, the recipient of the message is free to act as approrpiate to them.
Vassil Peytchev (Feb 20 2020 at 02:01):
Grahame Grieve said:
technically, this is a message that includes a history bundle
Exactly
John Moehrke (Feb 20 2020 at 02:01):
yes. does that get us to a solution?
Grahame Grieve (Feb 20 2020 at 02:01):
well, we think it does
Vassil Peytchev (Feb 20 2020 at 02:01):
It's still a bundle within the message
John Moehrke (Feb 20 2020 at 02:02):
so that is the bundle within the message bundle... right?
Grahame Grieve (Feb 20 2020 at 02:02):
yes. a history bundle inside the message bundle - so the message bundle wraps the existing defined history bundle with messaging semantics
John Moehrke (Feb 20 2020 at 02:04):
we can go that direction. It was a possibility. We just wanted to check one more time to see if these prohibitions were intentional or accidental
Grahame Grieve (Feb 20 2020 at 02:06):
intentional. And my conclusion is: they're a good thing.
John Moehrke (Feb 20 2020 at 02:06):
The history bundle seems to indicate that we must include 'all' which is not what we are wanting, we only want to include those that have changed in a period since the last notificaiton.
John Moehrke (Feb 20 2020 at 02:06):
http://build.fhir.org/http.html#history
Eric Haas (Feb 20 2020 at 02:06):
I still don't see how that fixes the issue of mixing and matching CUD within the message?
John Moehrke (Feb 20 2020 at 02:07):
Eric Haas said:
I still don't see how that fixes the issue of mixing and matching CUD within the message?
:-) it seems like a hack to me... get around a prohibition by encapuslation of that problem
Eric Haas (Feb 20 2020 at 02:08):
I actually do see it now. but I think transaction is what you need
Grahame Grieve (Feb 20 2020 at 02:08):
I don't think it is a hack. the semantics are clear: here's a message informing you of my transaction history
Grahame Grieve (Feb 20 2020 at 02:08):
history bundle seems to indicate that we must include 'all' which is not what we are wanting
I'm not finding language that suggests that
Eric Haas (Feb 20 2020 at 02:08):
instead of history...
John Moehrke (Feb 20 2020 at 02:09):
Eric Haas said:
I actually do see it now. but I think transaction is what you need
That would require a change to Subscription to allow us to subscribe to a transaction.
Vassil Peytchev (Feb 20 2020 at 02:09):
transaction within the message
John Moehrke (Feb 20 2020 at 02:09):
Grahame Grieve said:
history bundle seems to indicate that we must include 'all' which is not what we are wanting
I'm not finding language that suggests that
The very first line of the history description "The history interaction retrieves the history of either a particular resource, all resources of a given type, or all resources supported by the system."
Grahame Grieve (Feb 20 2020 at 02:10):
nah you wouldn't have to do that. can still put a transaction in a message. but given what you've said - the recipient decides how to handle the record of waht happened on the server - it's not a transction
Eric Haas (Feb 20 2020 at 02:10):
then why make a request?
Grahame Grieve (Feb 20 2020 at 02:10):
that language isn't meant to mean that it's comprehensive. Particularly given that one of the parameters is :
_since : instantOnly include resource versions that were created at or after the given instant in time
Eric Haas (Feb 20 2020 at 02:10):
with History
John Moehrke (Feb 20 2020 at 02:11):
okay we can use history with the _since parameter
John Moehrke (Feb 20 2020 at 02:11):
Eric I don't know what you are stating or asking and to whom
Grahame Grieve (Feb 20 2020 at 02:11):
umm. the _since parameter is on the request. I thought you were pushing the history, not making a request ?
John Moehrke (Feb 20 2020 at 02:12):
yes we are pushing the history
Eric Haas (Feb 20 2020 at 02:12):
Loosen up Bundle.entry.request to allow for messaging is how this thread started.
Grahame Grieve (Feb 20 2020 at 02:13):
so, presumably the push message includes the lastUpdated somewhere?
Eric Haas (Feb 20 2020 at 02:13):
So I assume you want to use Bundle.entry.request to instruct how to process the history bundles
Grahame Grieve (Feb 20 2020 at 02:13):
the message covers times from x to y, right?
Grahame Grieve (Feb 20 2020 at 02:13):
you have both times in the message?
Vassil Peytchev (Feb 20 2020 at 02:13):
Eric Haas said:
So I assume you want to use Bundle.entry.request to instruct how to process the history bundles
No, we are past that
John Moehrke (Feb 20 2020 at 02:13):
Eric Haas said:
So I assume you want to use Bundle.entry.request to instruct how to process the history bundles
when the bundle is a message...
Eric Haas (Feb 20 2020 at 02:14):
OK I missed that bit thanks @Vassil Peytchev
John Moehrke (Feb 20 2020 at 02:14):
Vassil Peytchev said:
Eric Haas said:
So I assume you want to use Bundle.entry.request to instruct how to process the history bundles
No, we are past that
im willing to have advocates for my desire
Lloyd McKenzie (Feb 20 2020 at 02:14):
The self link on the history should indicate what the '_since' value was, I believe?
Vassil Peytchev (Feb 20 2020 at 02:16):
im willing to have advocates for my desire
I believe the original intended use of message to be an abomination, so lets not go back there :-) I apologize for not paying
attention.
John Moehrke (Feb 20 2020 at 02:17):
so, I think I hear consensus that we continue to use a Message, but it has one entry which is a History Bundle carrying what we are trying to carry today. Right?
John Moehrke (Feb 20 2020 at 02:18):
we get around the history instance on all of a type because the messageHeader sets the context of what all because all is not all of that type (Patient) within the sender
Vassil Peytchev (Feb 20 2020 at 02:18):
Since the profile stated you can have multiple patients, it is a History Bundle per patient
John Moehrke (Feb 20 2020 at 02:18):
reasonable approach... I think.. and similar to an alternative we worked up today
John Moehrke (Feb 20 2020 at 02:19):
Vassil Peytchev said:
Since the profile stated you can have multiple patients, it is a History Bundle per patient
will you be at the face-to-face thursday? We looked for you today.
Vassil Peytchev (Feb 20 2020 at 02:19):
Already gone, but I can dial in
Grahame Grieve (Feb 20 2020 at 02:19):
we continue to use a Message, but it has one entry which is a History Bundle carrying what we are trying to carry today
yes
John Moehrke (Feb 20 2020 at 02:20):
okay. I don't know when or if we do it on friday. so Ill let you know
Grahame Grieve (Feb 20 2020 at 02:20):
we get around the history instance on all of a type because the messageHeader sets the context of what all because all is not all of that type (Patient) within the sender
I have no idea what this sentence means
John Moehrke (Feb 20 2020 at 02:20):
Grahame Grieve said:
we get around the history instance on all of a type because the messageHeader sets the context of what all because all is not all of that type (Patient) within the sender
I have no idea what this sentence means
3.1.0.12 history
The history interaction retrieves the history of either a particular resource, all resources of a given type, or all resources supported by the system.
John Moehrke (Feb 20 2020 at 02:21):
the "all" part of that is problematic if read strictly
Vassil Peytchev (Feb 20 2020 at 02:21):
But that is why you have a history per patient resource
John Moehrke (Feb 20 2020 at 02:21):
you gave the solution of using the timeframe indicated in the message header
Grahame Grieve (Feb 20 2020 at 02:21):
so I think you're confused between the interaction that fetches the history. and the rules for a history bundle
John Moehrke (Feb 20 2020 at 02:22):
Vassil Peytchev said:
But that is why you have a history per patient resource
are you meaning we can only have ONE patient per message?
John Moehrke (Feb 20 2020 at 02:22):
Grahame Grieve said:
so I think you're confused between the interaction that fetches the history. and the rules for a history bundle
Im reading the FHIR spec
Vassil Peytchev (Feb 20 2020 at 02:22):
No, you have multiple history bundles, each per patient
Grahame Grieve (Feb 20 2020 at 02:23):
you can build an arbitrary history bundle that has any combination of history entries that you want. There's no way to ask a server for that combination using REST, but that doesn't mean you can't specify for it to be built some other way
John Moehrke (Feb 20 2020 at 02:23):
Vassil Peytchev said:
No, you have multiple history bundles, each per patient
really? that is even more ugly... wrapping each patient in their own bundle?
Grahame Grieve (Feb 20 2020 at 02:23):
you don't need to do that.
Grahame Grieve (Feb 20 2020 at 02:23):
sorted with oldest versions last, and including deleted resources
Grahame Grieve (Feb 20 2020 at 02:24):
those rules apply to the bundle, I think
Vassil Peytchev (Feb 20 2020 at 02:24):
RIght now, MessgeHeader.focus is 1..* Patient. I was thinking you can just change the reference to bundle, but reading Grahame's reply, you don't have to.
John Moehrke (Feb 20 2020 at 02:24):
Grahame Grieve said:
you can build an arbitrary history bundle that has any combination of history entries that you want. There's no way to ask a server for that combination using REST, but that doesn't mean you can't specify for it to be built some other way
Ill put a footnote to the reader that I am sure will complain about "all"
Grahame Grieve (Feb 20 2020 at 02:25):
MessageHeader.focus will have to Bundle, yes
John Moehrke (Feb 20 2020 at 02:25):
One History Bundle that may contain 1..* different Patients... right?
Vassil Peytchev (Feb 20 2020 at 02:26):
Grahame Grieve said:
MessageHeader.focus will have to Bundle, yes
Single Bundle, magically built to contain histories of multiple patients (which is OK).
Grahame Grieve (Feb 20 2020 at 02:27):
One History Bundle that may contain 1..* different Patients... right?
yes
John Moehrke (Feb 20 2020 at 02:28):
Vassil are you suggesting that we should also allow replication at the message set of bundles? So many patients might be many history bundles with each only one patient, or could be one history bundle with many patients ... is this because you percieve one imlementation as easier?
John Moehrke (Feb 20 2020 at 02:28):
Im all for easier... but multiple levels of replication is harder on the recipient
John Moehrke (Feb 20 2020 at 02:29):
IHE we like to choose ONE
Vassil Peytchev (Feb 20 2020 at 02:30):
Not at all, I am simply restating Grahame's suggestion, with the focus on that certain person who will complain about the "all".
John Moehrke (Feb 20 2020 at 02:31):
ah.. I have the zulip URL to include in the footnote
John Moehrke (Feb 20 2020 at 02:31):
:-)
John Moehrke (Feb 20 2020 at 02:32):
thanks... we will look again in the morning to see if you all change your mind
Gino Canessa (Feb 20 2020 at 16:08):
John Moehrke said:
Eric Haas said:
I actually do see it now. but I think transaction is what you need
That would require a change to Subscription to allow us to subscribe to a transaction.
FYI, there are a lot of changes to Subscription in progress. This should be possible in the new version.
Also of note, there is a lot of discussion around what the notification bundle will be (specifically, the current plan is a new bundle type - I believe the FHIR-I call on Monday will have some discussion around that vs. messaging).
Last updated: Apr 12 2022 at 19:14 UTC
