Stream: implementers
Topic: DocumentReference and Binary
Brian Wright (Dec 29 2021 at 14:32):
It seems awkward to me that if you have a DocumentReference whose content is stored as a Binary resource, that the "reference" to the Binary from DocumentReference is via Content.attachment.url which is of type string.
Naively, it seems that if you had a property of type Reference at the DocumentReference.Content level, then you could leverage the FHIR server capabilities to do things like:
1) Post a transaction bundle with DocumentReference and Binary POST entries using temporary ids ("urn:uuid:xxx") and have the server resolve them.
2) Provide the ability to retrieve the DocumentReferences and content in one query against DocumentReference using _include=DocumentReference:<new_content_reference_search_param>
Thoughts? Thank you.
John Moehrke (Dec 29 2021 at 14:47):
Those are indeed useful if the document was always a FHIR Binary resource. The use-case for DocumentReference includes pointing at content that is not on a FHIR server, just content on a content server. Thus the reason it is a url, not a Reference. I would suspect that most of the time the .url is not to a FHIR server. Note also that what you are referring to is in the Attachment datatype, not necessarily limited to DocumentReference.
I encourage you to put in a Change Request. I do agree the benefits you point out are useful. I think some of the reference servers might already have some functionality like this that is not standardized.
Corey Spears (Dec 29 2021 at 16:28):
I agree with the sentiments expressed about the usefulness of having a Reference type in the Attachment data type. I am not sure what the best solution for adding this is given that we are discussing a data type used in a number of different contexts including normative resources. It certainly warrants a discussion (therefore a change request).
Corey Spears (Dec 29 2021 at 16:41):
Simply leaving the data type alone and adding to DocumentReference is something to consider.
John Moehrke (Dec 29 2021 at 16:42):
the Attachment datatype is normative. This does not mean it can't be improved, just restricts how it is improved.
John Moehrke (Dec 29 2021 at 16:43):
I suspect the need is just as useful everywhere Attachment datatype is used. so I think doing something only for DocumentReference is shortsighted.
John Moehrke (Dec 29 2021 at 16:44):
I would rather address the functionality without changing the structure. These functionalities could be driven by functionality requirements. These functionality are today assigned to Reference datatype, can't these same functionality be applied to attchment.url -- when the url is a URL to a FHIR server.
John Moehrke (Dec 29 2021 at 16:50):
Note that #1 is already supported and documented, as I indicated many reference servers will notice Bundle processing requirements typically reserved to Reference datatypes applied to attachment.url. Meaning if you have a Bundle with a DocumentReference, and that DocumentReference.content.attachment.url is a UUID, and there is a Binary with that UUID in the Bundle; these reference servers will fixup the .url element with the final Binary.id value... Thus the .url is processed as if it was a Reference datatype.
This is specified on the Attachment datatype definition
If the URL is a relative reference, it is interpreted in the same way as a resource reference.
no one has looked into similar processing for Query results #2
Lloyd McKenzie (Jan 03 2022 at 04:57):
There's no need to do anything to attachment to enable the desired behaviors.
For #1 (id substitution), the spec says Servers SHALL replace all matching links in the bundle, whether they are found in the resource ids, resource references, elements of type uri, url, oid, uuid, and <a href="" & <img src="" in the narrative.
Attachment.url is of type 'url', and thus it'll be replaced.
For #2, all that's needed is for DocumentReference to have a SearchParameter of type 'reference' that resolves the Attachment.url. Chaining isn't driven by the data type of the data element being searched, it's driven by the 'search type' of the SearchParameter.
You could certainly propose a standard SearchParameter be defined on DocumentReference to accomplish #2
Varun Vedantham (Mar 22 2022 at 19:20):
If we are using a DocumentReference with an Attachment.url, can the url element be a relative link/reference (such as Binary/<<id>>) or MUST the Attachment.url be an absolute url? We are running into an issue with a particular client application expecting only absolute urls and need to know if our implementation using relative reference does not meet the specification?
- Under Attachments, I see the following (see statement in bold) which I am interpreting as relative reference is acceptable
The actual content of an Attachment can be conveyed directly using the data element or a URL reference can be provided. If both are provided, the reference SHALL point to the same content as found in the data. The reference can never be reused to point to some different data (i.e. the reference is version specific). The URL reference SHALL point to a location that resolves to actual data; some URIs such as cid: meet this requirement. If the URL is a relative reference, it is interpreted in the same way as a resource reference.
- The url data type also permits any URI (XML representation: xs:anyURI). I interpret that as relative references are permitted for the url data type.
Thanks in advance!
John Moehrke (Mar 22 2022 at 20:53):
that should work
René Spronk (Mar 23 2022 at 07:22):
Definitely - there's no requirement that (for Binary or any other resource type) that the reference be absolute. It could be relative, or even a link to a contained (within DocumentReference) resource. If you're implementing against some FHIR Implementation Guide, it may state additional rules around this, or be silent on the issue (in which case the generic FHIR rules apply).
Last updated: Apr 12 2022 at 19:14 UTC
