Stream: implementers
Topic: Adding OperationOutcome to Bundle
Lloyd McKenzie (Sep 24 2021 at 02:29):
In discussing FHIR#32011, FHIR-I is proposing adding an 'outcome' element to Bundle to capture information and warning messages related to the processing of a bundle or transaction, or even to capture information related to the processing of a message or creation of a document. The proposals would also mean deprecating the Bundle.entry.search.mode of 'outcome', with the guidance to use the new element instead. Feedback about the idea is welcome.
Paul Church (Sep 24 2021 at 03:44):
I like the idea. I've been considering adding outcome entries to our implementation for some searchset situations but it's a real concern that any clients not anticipating this possibility could be broken by it. It would fix a lot of fhirpath constraint issues.
Daniel Venton (Sep 24 2021 at 12:17):
Since a bundle can contain any resource, and when it comes to search, it's recommended to include the OperationOutcome resource. Why wouldn't you just include the OperationOutcome resource to capture those messages related to the outcome of the bundle processing?
Lloyd McKenzie (Sep 24 2021 at 14:57):
In a batch-response, the entries in the response must exactly correspond to the entries in the request. You can't throw in another entry with an OperationOutcome without causing an error. Same goes for 'transaction'. You could throw an OperationOutcome into a document Bundle, but it would have to be navigable to from the Composition, which isn't necessarily what you want. Same deal with messages.
Lloyd McKenzie (Dec 06 2021 at 20:54):
After further discussion, we're leaning towards defining a standard header that could include an OperationOutcome as part of the result of an API invocation. With Bundles, it would be used for batch-response, transaction-response and history. In principle, it could also be used with POST, PUT and PATCH to return both the 'result' of a change (as the body) as well as the OperationOutcome. (At the moment you can only do one or the other.)
Grahame Grieve (Dec 06 2021 at 23:06):
FYI too: @James Agnew @Alexander Zautke @Paul Church @nicola (RIO/SS) @Lee Surprenant @Peter Jordan @Michael Lawley @Brian Postlethwaite
Brian Postlethwaite (Dec 06 2021 at 23:09):
My concern would be the size of the OpOutcome as a header (assuming you mean in json format - don't have that much space to mess with)
And then which to look for, the body (when it's a bad request) or the header if it's info messages.
Brian Postlethwaite (Dec 06 2021 at 23:09):
(and we already have the provenance header stuff too - not that I've used that yet)
Brian Postlethwaite (Dec 06 2021 at 23:10):
How about Bundle supporting contained, and including the outcome in there? (and would work for any resource too)
Grahame Grieve (Dec 06 2021 at 23:27):
which to look for,
That's an issue either way
Grahame Grieve (Dec 06 2021 at 23:28):
I really don't want to complicate bundle by allowing other kinds of resources
Brian Postlethwaite (Dec 06 2021 at 23:45):
Yes an issue either way, but this is another location to add to that list of possible locations.
nicola (RIO/SS) (Dec 07 2021 at 00:27):
Still didn't get problem clearly - is it about bundle in bundles or just add meta information to each entry of the bundle? -1 for header, especially with json/xml data - for me it is anti-pattern (HTTP is not the only interaction protocol). I really not a fan of idea sharing Bundle for everything - specialized containers would be better. And for us it is not a problem to extend bundle.entry with new properties. Does name "outcome" reflect this semantic?- for me it is more like "additional-info" or "metadata", "details"
Lloyd McKenzie (Dec 07 2021 at 03:16):
This isn't for each entry, it's for the overall processing of the interaction. Bundle.entry can already capture an outcome. As an example, when invoking a history interaction, you might pass back a warning that says "some history entries have been suppressed due to permission limitations" or "history between date X and Y is not available" or something like that
Michael Lawley (Dec 07 2021 at 06:38):
I may be remembering incorrectly, but had thought that it was always valid to wrap a response in an OperationOutcome. Or is that only for "operations" and not for things like search?
James Agnew (Dec 07 2021 at 13:38):
Putting a whole OO resource in a header might be trouble on some networks if the OO gets too big.
I know we added an interceptor in HAPI server that added validation results to response headers, and we've had a lot of reports of this causing things to fail as the response passes through various bits of network infrastructure. Despite the RFC not claiming any size limits on headers, there definitely seem to be some practical ones.
Lloyd McKenzie (Dec 07 2021 at 14:12):
Given the concerns about header size, would there be more support for the original proposal of adding an additional element to Bundle to support an overall OperationOutcome?
Eric Haas (Dec 07 2021 at 16:01):
Would this would change the batch "all or nothing' rules too?
Lloyd McKenzie (Dec 07 2021 at 16:03):
Not sure what you mean @Eric Haas
Eric Haas (Dec 07 2021 at 16:05):
if a batch fails because #3 of 4 Post fails what would it look like under the changes?
Lloyd McKenzie (Dec 07 2021 at 16:07):
A batch wouldn't fail if 3 of 4 posts fail. However, a transaction would fail. This OperationOutcome wouldn't be for errors - those would be handled as they always were. This would be for warnings and information messages that apply to the whole Bundle when the processing was 'successful'.
Paul Church (Dec 07 2021 at 17:50):
I remain in favour of this idea and I don't think an http response header is a good compromise due to header size issues.
Last updated: Apr 12 2022 at 19:14 UTC
