FHIR Chat · Allowed uri schemes for Bundle.entry.fullUrl and referenc... · implementers

Stream: implementers

Topic: Allowed uri schemes for Bundle.entry.fullUrl and referenc...


view this post on Zulip Lee Surprenant (Feb 11 2022 at 18:54):

I've read the proposed wording update for Bundle reference resolution at https://jira.hl7.org/browse/FHIR-29271?focusedCommentId=183020&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-183020
but I'm still not sure about something: are there any other supported uri schemes (besides http/s: and urn:) for fullUrl which should be supported by the server for reference replacement?

view this post on Zulip Lee Surprenant (Feb 11 2022 at 19:11):

I think I've seen Bundles that have other fullUrl structures before (though maybe invalid ones!). Right now, the only one I can recall is the Bundle that goes into smart health cards which uses a resource: scheme. Would anyone expect to be able to post entries with that scheme to a server and have it do reference replacement?

view this post on Zulip Lee Surprenant (Feb 11 2022 at 19:14):

I guess there is FHIR#31422 which relates to that (persuasive with modification) and what I'm trying to understand is whether / how that affects the resolution on FHIR#29271

view this post on Zulip Lloyd McKenzie (Feb 11 2022 at 19:43):

@Grahame Grieve

view this post on Zulip Josh Mandel (Feb 11 2022 at 20:59):

FHIR-31422 is the relevant decision here from my perspective; servers ought to be able to do "full URL matching" based on any scheme, and that's consistent with the "If the reference.value is a versionless..." logic from FHIR-29271, which you cite.

If you need "fhir base semantics" (like, to turn a relative reference into an absolute reference by appending to an inferred base) then you're limited (today) to the http/https schemes. (Even that's an unnecessary limitation; I think base semantics should work for ipfs and its brethren).

view this post on Zulip Lee Surprenant (Feb 11 2022 at 22:39):

I think I could get behind that. But then, in my opinion, listing only http/https examples under "Resolving absolute references" is a bit misleading...it would be nice to have at least one non-http example listed there to make it clear that "any" scheme could be considered an "absolute reference".
But that makes me wonder what would fall to the "Resolving other references." section...

view this post on Zulip Lee Surprenant (Feb 11 2022 at 22:41):

servers ought to be able to do "full URL matching" based on any scheme

would that include fullUrl with no scheme (i.e. no : delimiter), or is this what would full under the "Resolving other references" section?

view this post on Zulip Lee Surprenant (Feb 11 2022 at 22:48):

the one thing that gives me pause is the spec wants servers to replace references all over (even in the narrative text) and I'm wondering if its safe to do that for "any scheme". the risk of an unrelated href or img src attribute containing a long urn: value seems a lot lower than a string like "resource:0"

view this post on Zulip Josh Mandel (Feb 11 2022 at 23:02):

Sure, but the resolution rules are useful in places outside of "batch create" -- like, being able to publish a Bundle with one Organization's full hierarchy of clinics and practitioners with fullUrls like ipfs://{hash}/resources/Organization/123, and working references across the entries like Organization/123) (using absolute URIs for the references here is workable though).

[Or being able or resolve short urls like resource:0 across references in space constrained QR. Edit: we don't need relative URIs in this references for this one; absolute are shorter].

If you're preparing a Bundle specifically to call batch create and you want to avoid ambiguities, you could always use URNs.

view this post on Zulip Josh Mandel (Feb 12 2022 at 02:56):

(btw will you share a pointer to the language about replacing narrative? It sounds familiar but I'm having trouble finding it.)

view this post on Zulip Lee Surprenant (Feb 12 2022 at 03:47):

sure, thats from https://build.fhir.org/http.html#trules
specifically this bit:

Servers SHALL replace all matching links in the bundle, whether they are found in the resource ids, resource references, elements of type uri, url, oid, uuid, and <a href="" & <img src="" in the narrative. Elements of type canonical are not replaced.

view this post on Zulip Lee Surprenant (Feb 12 2022 at 03:49):

I'm not sure if servers actually implement that bit or not though. I "kind of" get replacing href values but really not sure what the use case is for an img src attribute that points at a resource url.


Last updated: Apr 12 2022 at 19:14 UTC