Stream: implementers
Topic: Attachment.contentType for FHIR
Simone Heckmann (Feb 25 2022 at 14:54):
Is there any recommendation on how to set Attachment.contentType if the Attachment.url points to a FHIR-Resource (e.g. a Bundle) which could be retrieved in either xml or json?
Is application/fhir a thing?
Lloyd McKenzie (Feb 25 2022 at 14:55):
We don't have a notion of a URL that supports content negotiation for different mime types. Feel free to submit a change request
Simone Heckmann (Feb 25 2022 at 15:01):
So, currently all I could do is wrap a fixed representation of the Bundle into an Binary and set Attachment.contentType according to Binary.contentType ?
Lloyd McKenzie (Feb 25 2022 at 15:14):
No, you could point to a FHIR endpoint, but the mime type you declare needs to be whatever you'll get from that endpoint by default (without content negotiation)
Lloyd McKenzie (Feb 25 2022 at 15:15):
For some servers, that's JSON, for some it's XML, for some it's HTML. For some, it'll be an error.
Simone Heckmann (Feb 25 2022 at 15:17):
Alternatively, could a Server expose one DocumentReference.content each for every representation it supports? One with an application/fhir+xml Attachment, the other with an application/fhir-json attachment?
Lloyd McKenzie (Feb 25 2022 at 15:18):
If you include the _format in the URL - and the server supports it.
John Moehrke (Feb 25 2022 at 16:07):
I have recommended that .contentType when a .url is used be specified as the preferred mime-type at that url; but that the http negotiate can be used to get a different mime-type that the client would prefer. normal http mime-type negotiation
John Moehrke (Feb 25 2022 at 16:08):
thus, I could have a url that I indicate contentType is fhir/json... but if a client wants PDF, and that server can provide PDF, then PDF can be returned.
John Moehrke (Feb 25 2022 at 16:09):
I think this is defined in Binary... so I expected it to apply everywhere Binary can be used, and attachment.url is one of those places.
John Moehrke (Feb 25 2022 at 16:10):
thus .contentType is simply the mime-type that you are guaranteed you can get, but you are free to use http negotiate to ask for anything you prefer.
René Spronk (Feb 25 2022 at 16:22):
That's also my understanding of Binary, IMHO one DocRef would suffice, one can always try and request a different mime type. However, if a server wishes to make it known that it can resturn a PDF, a HTML and a fhir+json version, you may need multiple DocRefs.
Lloyd McKenzie (Feb 25 2022 at 16:24):
Why would you need multiple DocRefs when you can have multiple DocRef.content elements?
John Moehrke (Feb 25 2022 at 16:43):
in FHIR core... yes multiple .content could be used... in IHE-MHD one uses multiple DocumentReference
Last updated: Apr 12 2022 at 19:14 UTC
