FHIR Chat · Task 12657 · implementers

Stream: implementers

Topic: Task 12657


view this post on Zulip Grahame Grieve (Feb 15 2017 at 19:46):

GF#12657 includes an instuction to add a rather bizarre note to the Media resource:

This resource can embed the image information directly through the attachment.data element. However, good practice is generally to use attachment.url to point to a Binary resource. Servers will frequently be able to persist Binaries in purpose-dedicated repositories more suitable to potentially large artifacts.

view this post on Zulip Grahame Grieve (Feb 15 2017 at 19:47):

I don't understand this rationale, and it will cause questions for implementers. In what sense are implementers not allowed to do purpose dedicated respositories for Media? that's a *stupid* comment

view this post on Zulip Grahame Grieve (Feb 15 2017 at 19:47):

I've added it, but I'd like to take it out

view this post on Zulip Lloyd McKenzie (Feb 15 2017 at 20:09):

You're allowed to do purpose-dedicated repositories for Media or Observation or anything if you like, but it's less common (and useful) than for Binary. Binary has no searchable metadata and is always binary information. Media is a resource just like Observation where there's a whole bunch of Metadata. And it's useful to be able to retrieve the Media instance without necessarily retrieving the associated binary blob. Thus the recommendation to stick the raw data of the image/video/whatever in Binary rather than including it directly.

view this post on Zulip Grahame Grieve (Feb 15 2017 at 21:06):

that's a much better reason. only it's not really valid because of _summary

view this post on Zulip Lloyd McKenzie (Feb 16 2017 at 00:01):

_summary filters a bunch of things. If you use _summary, you exclude the mime type, size and other information until you actually retrieve the whole thing.


Last updated: Apr 12 2022 at 19:14 UTC