FHIR Chat · Normative (breaking?) change to Bundle fullUrl requirements · implementers

Stream: implementers

Topic: Normative (breaking?) change to Bundle fullUrl requirements


view this post on Zulip Lloyd McKenzie (Sep 28 2021 at 02:22):

We're proposing to refine and slightly loosen the requirements for fullUrls on Bundle.entry to more clearly reflect what our original intention was (as well as what's useful/appropriate). However, loosening normative requirements is technically a breaking change, so we're seeking community review and feedback on this proposed clarification. If you implement Bundles - and in particular batch or transaction, please read FHIR#31354 and comment here on whether you agree or disagree with the proposed change.

view this post on Zulip John Silva (Sep 28 2021 at 12:10):

What does this statement mean; can you give an example?

"invoking or responding to an operation where the body is not a single identified resource; "

view this post on Zulip Lloyd McKenzie (Sep 28 2021 at 14:20):

If you're invoking $validate and are passing in a resource that 'exists' somewhere, the fullUrl would be the location of that resource. However, the OperationOutcome you get back wouldn't have a resource id and doesn't exist on a specific server, so no fullUrl would be needed. If invoking $graphql, there's no resource payload on the request at all, so there also wouldn't be a fullUrl.

view this post on Zulip Lloyd McKenzie (Sep 28 2021 at 14:20):

Feedback on how to be clearer is welcome.

view this post on Zulip Corey Spears (Sep 28 2021 at 15:05):

Does this affect only batch and transaction bundles? Document bundles with use of fullUrl feels a little bit wonky. It is fine if the resource fullURL (when it is a url and not a urn) exists on the server that the document exists on, but there is no guarantee of that (the document itself may have passed through several servers) and there is no guarantee that the entry resources exist outside of the document.

This has been a point of some confusion that I think we may see more of when FHIR native documents become more prevalent. We should at least have clearer guidance regarding how this should work and what the expectations are (more clearly laid out) or consider taking another look at this to see if there is a way to simplify.

view this post on Zulip Vassil Peytchev (Sep 28 2021 at 18:10):

In a document Bundle the fullUrl is necessary for references among the resources in the Bundle, isn't it?

view this post on Zulip Corey Spears (Sep 28 2021 at 18:25):

Yes, that is the way it is currently defined, though it could be more explicit in the documents documentation. The FHIR Documents section (https://www.hl7.org/fhir/documents.html) doesn't even mention fullUrl.

view this post on Zulip Oliver Egger (Sep 28 2021 at 19:01):

@Corey Spears we need fullUrl in documents when we do not have identifiable resources (e.g. CDA to FHIR transformation)

view this post on Zulip Lloyd McKenzie (Sep 28 2021 at 19:14):

fullUrl is needed any time resolution is necessary - which is the case for all entries in a document or message and may be true for some entries in transactions - we appear to presume it's also always true for 'collection' Bundles, though there's no documented requirement there. We've also asserted that It's true when the entries correspond to entries that represent content available on a server, though it's not entirely clear to me why we require this.

view this post on Zulip Amy Li (Oct 07 2021 at 18:58):

Lloyd McKenzie said:

fullUrl is needed any time resolution is necessary - which is the case for all entries in a document or message and may be true for some entries in transactions - we appear to presume it's also always true for 'collection' Bundles, though there's no documented requirement there. We've also asserted that It's true when the entries correspond to entries that represent content available on a server, though it's not entirely clear to me why we require this.

Hi Lloyd,
the requirements around Bundle.fullUrl seems going backward from build to build of the validator v3.0.2. What I mean is that in the older builds of the _cli.jar validator, it never complained about missing Bundle.fullUrl for OperationOutcome entry in the Bundle. In the new builds since 2021-02-18, the validator starts to raise error for the same Bundle document I have which is a searchset. The error is

Error @ Bundle.entry[1] (line 733, col12) : Except for transactions and batches, each entry in a Bundle must have a fullUrl which is the identity of the resource in the entry

Is this the requirement that you are trying to loosen? If not what is the reason for that a fullUrl is now needed for OperationOutcome in the Bundle?

Thanks,

Amy

view this post on Zulip Lloyd McKenzie (Oct 07 2021 at 19:17):

The rule was always there (and is, in fact tighter than it needs to be). We're trying to create additional clarity in R5. Feel free to submit a change request around this, though there's also a proposal to move OperationOutcome in a Bundle outside of entry entirely and deprecate that approach.

view this post on Zulip Amy Li (Oct 07 2021 at 21:15):

Thank you Lloyd.
It makes perfect sense to move OperationOutcome outside of Bundle.entry. For one obvious reason, OperationOutcome is not counted in the Bundle.total and for another it has different characteristics as other resources. I would definitely welcome this change in the future releases.


Last updated: Apr 12 2022 at 19:14 UTC