Stream: implementers
Topic: What should the path to a non-FHIR resource be?
Tim Berezny (Jan 18 2021 at 17:18):
I'm trying to link to geoJSON files from the location resource (using the boundary-geojson extension).
If I use {fhir_base_url}/Location/123 for a specific location, and the extension points to a geojson file, would it be ok to use the following?:
- {fhir_base_url}/boundary-geo-json/456
Other alternatives I've considered:
- {fhir_base_url}/attachments/geo-json/456
- {fhir_base_url}/files/boundary-geo-json/456
- {fhir_base_url}/other-resources/boundary-geo-json/456
- {another_subdomain_base_url}/boundary-geo-json/456
A similar question applies for pointing to PDF files. What is the best approach for building a url path for non-fhir resources on a FHIR server?
Vassil Peytchev (Jan 18 2021 at 17:24):
I don't think {fhir_base_url}/geo-json/456 is OK to use. I think any solution that does not include {fhir_base_url} is OK (e.g. 4), but not necessarily requiring another sub-domain in the URL.
I would love to hear what others think...
Jean Duteau (Jan 18 2021 at 18:14):
i think that it depends on how you are serving them up. It is actually possible to serve them up as Binary resources and then you could use FHIR URLs to point to them. If they are pointed to as just http files, then you can use any URL you want, but I tend to agree with @Vassil Peytchev that using the {fhir_base_url} would confuse your implementers since it would seem like they are FHIR resources when they are not.
Tim Berezny (Jan 18 2021 at 18:23):
That's my sense too - that returning non-FHIR resources from a FHIR server might confuse implementers... but at the same time I feel like is a common enough scenario that there might be some kind of best practice for this (especially considering the attachment data type, which doesn't have a reference element so I can't point to a binary resource.)
Jean Duteau (Jan 18 2021 at 18:27):
you could just put the URL to the Binary resource in the attachment datatype, but your point is still valid - it might be useful that anywhere there was an Attachment data element that the resource also have a Reference(Binary).
Tim Berezny (Jan 18 2021 at 18:47):
Yes, I could put the binary in the attachment datatype - and I'd probably do that for small files, but this file can be a large so I'm forcing retrieving the attachment separately in this case.
Lloyd McKenzie (Jan 18 2021 at 23:01):
Technically, there's no rule that all paths beneath a fhir_base_url must be valid FHIR references. However, the risk with having such paths is that it's possible they might collide with future FHIR capabilities. They might also be confusing to implementers. And you certainly can't point to them from FHIR as if they are anything other than arbitrary URLs.
Grahame Grieve (Jan 19 2021 at 01:01):
you can be sure that we will never introduce resources that have characters such as -_.$@%^ etc in their name
Lloyd McKenzie (Jan 19 2021 at 01:22):
We do make use of $ -for operations. Are we confident we wouldn't ever introduce other constructs that use some of these things?
John Moehrke (Jan 19 2021 at 13:30):
This seems like a clear case for putting the content into Binary, and having a DocumentReference describing that content and pointing at the Binary. Size is not an issue. (Note that doing a GET on a Binary where the http negotiation includes the native mime-type would transmit the native content, not encapsulated in Binary and not base64 encoded)
Last updated: Apr 12 2022 at 19:14 UTC
