FHIR Chat · Attachment.url relative reference · implementers

Stream: implementers

Topic: Attachment.url relative reference

Brett Esler (Apr 01 2016 at 03:49):

Hi all - looking for advice on use of Attachement.url (in a DocumentReference) making a relative reference to a Binary resource all in the same Bundle (in this case a message) - so this is not a ResourceReference so what is the right way to do it...

Brett Esler (Apr 01 2016 at 03:51):

btw did not want to embed the data in the Attachment - wanted to keep a Binary resource

Bryn Rhodes (Apr 01 2016 at 04:13):

Why use a Binary resource in that case, why not just use the content element of the Attachment?

Brett Esler (Apr 01 2016 at 04:20):

true - sender has a preference .... after some discussion landed on

  <entry>
     <fullUrl value="urn:uuid:6380E47C-9C9C-43CD-9206-7AE57C0C7247"/>
    <resource>
      <Binary>
      </Binary>
    </resource>
  <entry>
  <entry>
     <fullUrl value="urn:uuid:15EF8B27-9977-4DC0-AF16-4D379907EC72"/>
    <resource>
      <DocumentReference>
        <content>
            <attachment>
               <url value="urn:uuid:6380E47C-9C9C-43CD-9206-7AE57C0C7247"/>
           </attachment>
       </content>
      </DocumentReference>
    </resource>
  <entry>

Brett Esler (Apr 01 2016 at 04:23):

as per description in http://hl7.org/fhir/bundle.html#references

Brian Postlethwaite (Apr 01 2016 at 05:51):

The binary content in this instance is a PDF, and some systems enjoy storing the binary content outside the database, and can decide based on size of the content.

Elliot Silver (Apr 01 2016 at 16:42):

The content element of Attachment is evil. I really would like to be able to retrieve the information about the content independent of the retrieving the content. And since Attachment is a datatype, not a referenced resource, if you have a resource with an attachmet (or worse, multiple attachments), you never know when retrieving the resource that you might end downloading multiple megabytes (or gigabytes) of data.

Grahame Grieve (Apr 02 2016 at 04:40):

you can ask for a _summary

Eric Haas (Apr 04 2016 at 16:03):

or profile it out of the datatype.

Elliot Silver (Apr 04 2016 at 18:06):

@Grahame Grieve yup, and that's a recent improvement, but if there are multiple Attachments, _summary only gives you the ability to retrieve all or none. If there are multiple Attachments, you can't get one at a time. Hmm, I support combining one _summary fetch, with follow-up use of _elements might solve some problems, but can you use _elements to get the first, second, third repetition of an element separately? @Eric Haas yes, can profile, but unless there is some guarantee that all sources (or the server itself) will tag the resources compying with that profiles, and you can thus filter on profile in your fetches, you need to be prepared to encounter non-compliant resources with inline content.

Grahame Grieve (Apr 07 2016 at 20:48):

yes. agree. but I don't think we can do something useful about this without losing control of complexity

Last updated: Apr 12 2022 at 19:14 UTC