Stream: implementers
Topic: Reference file from Attachment
Andreas Keil (Feb 14 2018 at 14:07):
Hi, I have the following use case: I want to store a pdf next to a DiagnosticReport (DR) resource without having to embed the pdf into the DR to prevent loading not required data and to decrease loading time as those pdfs can be quite large. I know I can store the pdf inside DR.presentedForm as an Attachment but I don't want the files to be inline.
I can imagine three possible solutions:
1) post the files as a Binary and reference the Binary from the DR or the Attachment
2) Set the Attachment.uri to the Binary
3) Use an extension
In my eyes, posting the files as a Binary and referencing them from the Attachment (not with Binary.uri) is the best way to achieve this. What do you think?
Patrick Werner (Feb 14 2018 at 14:14):
I would suggest to post the PDF to a non FHIR REST Endpoint (as i assume that the FHIR Endpoint would put the PDFs in a DB) and then link to it from DR.Attachment in a second step).
Simone Heckmann (Feb 14 2018 at 14:37):
AFAIK, Vonk treats Binary content differently and stores it in files rather than the database, or at least it's on their roadmap (@Christiaan Knaap ?)
Not sure how HAPI deals with it. As far as handling the references is concerned, I think it's best to align with how IHE MHD treats the Reference between DocumentReference and Binary...
Grahame Grieve (Feb 14 2018 at 18:59):
I'm not sure what the difference between (1) and (2) is, and I'm not sure how (3) could be better. Certainly the intent we had would be an attachment.uri pointing to a binary somewhere, potentially a Binary resource.
Patrick Werner (Feb 15 2018 at 15:00):
the only downside of attachment.uri is that it can't be used to send a DiagReport & Binary in one transaction bundle. Maybe it would be nice to add attachment.reference(binary), this would allow the desired usage of transferring both resources at once.
Adding the PDF in the attachment at attachment.data would lead to the PDF only living inside of the DiagReport with the downside of a huge resource, sometimes you only want the DiagReport without the PDF, sometimes you just want to get or reference the PDF without the DiagReport.
Do you think adding attachment.reference(Binary) would make sense to solve these problems?
Elliot Silver (Feb 15 2018 at 15:13):
Attachment.uri can certainly point to a Binary, so you can transmit both in a bundle.
Patrick Werner (Feb 15 2018 at 16:30):
at the point of transmission i don't know yet the ID and therefore also not the uri of the Binary resource. If this would be a reference (or additional reference item) i could add a temporary ID (urn:uuid:) and the server would return the transaction bundle after posting with the actual given resource IDs. This isn't possible, as Attachment doesn't contains a reference, only uri - which wouldnt be replaced (at least we understood and tested)
Grahame Grieve (Feb 15 2018 at 20:29):
attachment uri should be replaced. according to the spec.
Grahame Grieve (Feb 15 2018 at 20:30):
for this specific scenario, in fact.
Grahame Grieve (Feb 15 2018 at 20:30):
if the server doesn't, make a bug report against it
Patrick Werner (Feb 16 2018 at 12:33):
thanks for the clarification @Grahame Grieve i wasn't aware of this part of the spec.
Simone Heckmann (Feb 16 2018 at 13:50):
The fact that you can't query a Document with Metadata (DocumentReference) and Content (Binary) in one step, because uri doesn't support _include still disturbs me...
Grahame Grieve (Feb 16 2018 at 19:56):
you can make a task...
Christiaan Knaap (Feb 20 2018 at 10:35):
@Simone Heckmann : Yes, it is on the roadmap to provide full support for Binary. Storing that in the database or elsewhere is an implementation choice then. Storing files in db blobs is not really a problem anymore by the way for several databases.
Chris Grenz (Feb 20 2018 at 17:36):
@Simone Heckmann I'd definitely support a change to support fetching both DR and Binary in a single fetch. Could take a number of forms - I'm not sure what guiding principles are in place for referencing Binary resources, but it seems like the "metadata" resources should support references to Binary.
Elliot Silver (Feb 20 2018 at 20:37):
@Christiaan Knaap, @Simone Heckmann I can see adding support for _include, when the target is a Binary, but would you also follow the uri if it didn't point to a FHIR resource?
Grahame Grieve (Feb 20 2018 at 20:38):
typically we'd say, server discretion, but IGs could make further rules
Elliot Silver (Feb 20 2018 at 20:39):
My first thought is that you can't put the result in a Bundle, so unless it is a FHIR resource, I'm not sure how you'd return it.
Grahame Grieve (Feb 20 2018 at 20:49):
sure you can - wrap it in a binary.
Christiaan Knaap (Feb 20 2018 at 21:18):
Had not thought of supporting that. Wrapping in a Binary would be possible, if we can relate a stable id to the actual 'file'.
Lloyd McKenzie (Feb 20 2018 at 23:27):
Could allow it to be an on-the-fly UUID if it's in the same Bundle.
Patrick Werner (Feb 21 2018 at 09:29):
Could allow it to be an on-the-fly UUID if it's in the same Bundle.
would be a similar behavior to posting a binary linked through attachment inside of a Bundle.
Elliot Silver (Feb 21 2018 at 17:12):
I think that's an interesting approach, but if the community wants it, I think we need to move quickly before Bundle behavior becomes locked down.
Lloyd McKenzie (Feb 21 2018 at 17:46):
This wouldn't be a change to Bundle. It would be an additional feature of _include - and is something that would be allowed as part of our inter-version compatibility rules for normative. Adding the capability wouldn't break existing systems - they'd just see a search parameter they didn't support and behave accordingly.
Elliot Silver (Feb 21 2018 at 17:49):
Really? Does anyone expect to get a temporary guid bundle internal reference back on a query?
Lloyd McKenzie (Feb 21 2018 at 17:50):
They'd only get that if they invoked a query that used a search parameter that uses the new mechanism - which means they should expect it :)
Elliot Silver (Feb 21 2018 at 17:52):
OK, makes sense.
Christiaan Knaap (Mar 06 2018 at 12:47):
I think a search result bundle is very different from a posted Bundle (of type batch or transaction). In the former case the server hosts the resources in the bundle. They happen to be bundled for convenient retrieval, but should also be individually retrievable. By their logical id. So when the client comes back to retrieve one of the Binaries individually, using the id from that resource in the bundle, it should get the same Binary. A UUID could be that id, but then the server has to be able to map that to the correct Binary. That is wat I meant by having a 'stable id'. I think this behaviour should not be dependent upon a specific usage of _include.
Eric Haas (Apr 23 2018 at 19:22):
I looked for trackers to address the _include issue that "The name of the search parameter which must be of type reference". Have n't found any (which doesn't mean they are not there) I have a use case for DocRef where it would be nice if the search parameter could be and Attachment datatype too, I think canonical too. Where are we with this?
Elliot Silver (Apr 23 2018 at 23:21):
@Eric Haas , if you want the file referenced by the attachment included in the result, use the data element, rather than the url. I recognize that this requires coordination of the DocRef creator and reader, while the _include approach doesn't, but it is supported, and you can use _summary or _elements to include the data or not as you'd prefer.
I don't think including the content of arbitrary urls in a search result makes sense. What if the URL is to an ftp server?
Further, I'm not sure that, even if you could specify it in the query, it would be solve your problem. How would you include the arbitrary file in the returned bundle? There is no guarantee that the target will be a BackboneElement, which is needed to include it in a Bundle.
Eric Haas (Apr 24 2018 at 02:24):
@Elliot Silver I understand that is an option, but what if some clients want it and others do not. By inlining the content you limit the clients options.
Eric Haas (Apr 24 2018 at 02:25):
The expectation of the _include would be for FHIR endpoints. I don't think would expect any old url to return anything.
Elliot Silver (Apr 24 2018 at 02:47):
Well, clients that don’t want it can use _summary or _elements to exclude it, but I agree, I don’t think putting it in the attachment data is a nice solution.
However, I’m not thrilled with the _include approach. If we interpret _include to have meaning for urls to FHIR endpoints, then you are proposing to trade the “inefficiency” of two retrieves for the inefficiency of the base-64 encoded data in the body of a bundled Binary. I’d rather do two retrieves.
Christiaan Knaap (Apr 24 2018 at 07:30):
It would also clutter the implementation of _include in FHIR Servers. I'm not too enthousiastic.
Brett Marquard (Apr 24 2018 at 10:23):
I am torn, but agree _include doesn't feel quite right. When a client gets back the DocumentReference.Attachment.url, is there anyway to tell it's referencing a FHIR resource? attachment data type
Grahame Grieve (Apr 24 2018 at 21:47):
the server can know by knowing the target
John Moehrke (Apr 26 2018 at 21:43):
I have heard interest from the MHD crowd for this... The fact that attachment.url is treated differently is continuing to present issues... I think we fixed the fixup thing, why can't we clarify the _include would work when the url points at a Resource type (including Binary)?
Eric Haas (Apr 26 2018 at 22:43):
Since Attachment provide option of reference or inline b64 how about alt approach of creating a custom search param to request option of url or inline (b64) content ( at servers discretion of course).
John Moehrke (Apr 28 2018 at 12:51):
Eric, so you would have the server re-encode the data from one to the other? That is far more than I was looking at, and it would not work for MHD. I just want a way to include the content at attachment.url in the results Bundle. It seems simple enough... right?
Last updated: Apr 12 2022 at 19:14 UTC
