Stream: implementers
Topic: Conditional references outside of transactions
Johannes Faber (Dec 18 2018 at 12:29):
I'm wondering what the rational behind the decision was to support conditional references only for transactions. I haven't found a clear answer on this in one of the previous topics, but it seems that the main reasons are (1) that there better ways to resolve references in client-controlled scenario and (2) it causes too much trouble allowing it.
However, it might make sense to allow it in message based communication as well. In messages composed of different resources that are processed in some server-defined way, the problem of resolving references is quite similar to when processing transactions. Was it by intention to not allow it in message processing? What would be the recommended way to resolve references in such scenarios?
Lloyd McKenzie (Dec 18 2018 at 15:03):
With messaging, there's generally no assumption that the receiver has any RESTful search capability at all, so supporting conditional references seemed a bit of a stretch. As well, there's no history of supporting that capability in either v2 or v3 messaging, so it wasn't obvious there'd be a use-case.
Johannes Faber (Dec 19 2018 at 08:49):
Hm, not sure if I can follow the first argument, because it seems kind of unlikely to me that many receivers will support FHIR messages without having any capabilities to search. How the message is exactly processed is not defined by the standard anyway, but up to the definition of the server. As the standard is currently defined (if I read it right) it is not possible to include conditional references in a message bundle without being syntactically incorrect. For this reason, one is practically forced to include all referenced resources in a message bundle because otherwise it is not possible to resolve the references in the message. I guess this is the way how v2 and v3 worked, sending all relevant information within the message. Assuming that many servers won't support FHIR messages without having at least some FHIR REST capabilities, supporting conditional references in messages would give a little more flexibility.
Lloyd McKenzie (Dec 19 2018 at 15:05):
Most systems that I'm aware of that support messaging don't expose RESTful search interfaces for either much or any of their data. Any search capabilities that exist are generally exposed using messaging. For those that build a FHIR interface on top of a v2 interface, RESTful search can be difficult or possible to build. I'm not saying it's not possible to have both, just that there was no assumption that both would exist.
That said, we can certainly explore the possibility of allowing conditional references in messages if that's something the implementer community would find useful - feel free to submit a change request :)
René Spronk (Dec 19 2018 at 16:32):
I'm all in favor of allowing them(conditional references) in REST (not just in REST transactions), but in messaging? or in documents? It's not really the nature of those interoperability paradigms. The response to your yet-to-be-created change proposal could be that your use case apparently isn't a good fit for messaging, and that you should use some other Bundle via REST instead.
Simone Heckmann (Dec 20 2018 at 18:25):
Wouldn’t it be more appropriate to use Logical References in Messaging instead of Conditional References?
That way it would be up to the receiver to decide if and how to resolve the identifier to a Resource.
Simone Heckmann (Dec 20 2018 at 18:26):
...without the assumption that the receiver understands Restful search
Johannes Faber (Dec 21 2018 at 09:49):
Using logical references will only work if the sender knows exactly which references are known to the receiver. In complex synchronization scenarios with more than two participants this might not be the case, because all the participants only know a subset of all given ids for a resource. In order to increase the chance that a receiver knows the referenced identifiers, the sender would need to include all known (to the sender) identifiers in a logical reference which is not possible because it has cardinality 0..1 in the standard. With a conditional reference on the other hand, you could search for all known identifiers. So, logical references are a solution, but only if there is for every resource a 'reference id' known to all participants.
René Spronk (Dec 21 2018 at 15:35):
Messaging (by definition) is loosely coupled. One can't ever assume the receiver is already aware of any prior data pertaining to what will be sent in a message. Nor can one assume that any part of a message will be persisted; nor can one assume that a receiver will have access to the sender, or that it senders and/or receivers support querying. As such all references within a message should resolve within that very same message (whether absolute, conditional, logical or otherwise). If a reference doesn't resolve within a message, then it's effectively an unknown which in all likelihood will be ignored by the receiver.
Johannes Faber (Dec 21 2018 at 16:24):
This seems to be a quite restricted interpretation of messaging. Even the FHIR specification speaks of a contract between participants, so in general, there can be some kind of agreement about how messages are processed. However, your view on messaging in which messages always contain their entire context is certainly quite clean; with the (only?) disadvantage that you're sending a lot of redundant information around.
Lloyd McKenzie (Dec 21 2018 at 16:27):
Historically, that's how messaging has worked. The only way to get data was to receive it in the message. Query support in messaging was dicey at best. It may be that with FHIR, there may be room for a hybrid approach where messages can be lighter-weight and there's an expectation for systems to support some RESTful data access to acquire content not embedded in the message. However, we don't have enough experience yet to know whether this will be a common pattern.
John Moehrke (Dec 21 2018 at 16:47):
I think it is very reasonable to have a hybrid approach if it is defined as part of an Implementation Guide. That is to say a use-case can be addressed by an Implementation guide that makes it clear those claiming conformance to the implementation guide will use Messaging for X and will use REST for Y... I have seen something like this, but rather than using Messaging it specifies the REST Subscription.
René Spronk (Dec 22 2018 at 17:56):
@Johannes Faber I carefully used the sentence "one can't assume x,y or z". Messaging requires agreements to be in place between applications, and in the context of such an agreement you could construct any hybrid approach. But failing such explicit agreement, one should assume that messaging is used in its historic sense: fairly restricted, akin to historic messaging approaches as used by HL7v2, HL7v3, EDIFACT, DICOM, X12 and heaps of other tried-and-tested messaging protocols.
Lloyd McKenzie (Dec 22 2018 at 21:02):
Realisticly, messaging requires explicit agreement no matter what - it can only be used within a closed community that's agreed on the messaging events, payloads and permitted responses. Setting expectations for RESTful support at the same time is reasonable.
Last updated: Apr 12 2022 at 19:14 UTC
