Stream: implementers
Topic: Media resource as attachment url
Rowan Foster (May 11 2016 at 03:34):
Is it appropriate to link to a Media resource as an attachment url? eg from Observation.valueAttachment.url
To me the spec implies that this is not appropriate. However it feels like a reasonable thing to do if I want to make an image (or other media) available via both the Media and Observation resource without duplicating the media file.
Josh Mandel (May 11 2016 at 03:44):
It's a bit... indirect. In your Media, are you including content via base64 in .content.data?
Josh Mandel (May 11 2016 at 03:46):
(I say "indirect" because it requires two hops to resolve: the first hop resolving to a Media resource with mime-type of application/json+fhir -- erm, and the content type would need to be worked out clearly, or a _format embedded in the link -- and the second hop to get the actual image.)
Josh Mandel (May 11 2016 at 03:46):
It would be cleaner for clients if you just referred to the image directly in both cases.
Rowan Foster (May 11 2016 at 03:50):
Yeah that is my feeling too. I'm considering the media link due to concerns of security of the image URL. The Media resource already has the meta-data required to determine whether the client is allowed to view the given image ie Media.subject and Media.meta.security
Rowan Foster (May 11 2016 at 03:55):
And by having a non-FHIR url it means that for a client to provide an image they will need to use a non-standards (FHIR) method thus annoying for 3rd party client implementations.
Rowan Foster (May 11 2016 at 03:58):
I've been looking at the Binary resource as well, but again as that does not deal with security related meta-data there seems to be no standard way to allow a client to upload media but also prevent access by those who should not be able to view it
Grahame Grieve (May 11 2016 at 10:46):
you can refer to an media resource from a url, sure. But... what media type is the client going to ask for? Do you need to specify that in the url using _format?
Last updated: Apr 12 2022 at 19:14 UTC
