Stream: implementers
Topic: Add an attachment to a /ReferralRequest
Tim Berezny (May 24 2017 at 19:48):
Hi, this is my first post here, i see it's very active! I would like to ask a question:
I'm developing a /ReferralRequest module (to receive eReferrals). One need i have is to send attachments with the payload (e.g., PDFs.). I'm trying to figure out the best way to do it, but can't quite figure out what the most accepted approach is. So far I've considered:
1) Using ReferralRequest.SupportingInfo to reference a /DocumentReference
2) Using ReferralRequest.SupportingInfo to reference a /DocumentManifest
3) Using referralRequest.SupportingInfo to reference a /Attachment
4) Adding an extension
5) Other?
I want to chose one core way that is the simplest yet flexible approach, so that it could handle one or many documents. What would be the best way to attach a document to a /ReferralRequest.
Any assistance is greatly appreciated!
Lloyd McKenzie (May 24 2017 at 20:59):
If it's a pure PDF with no metadata, I'd use supportingInfo to point to a Binary. If you've got metada, then DocumentReference or Media could work, with a preference for Media. You can't point to it as an Attachment because that's a data type.
Elliot Silver (May 24 2017 at 22:48):
@Tim Berezny DocumentManifest is to identify a collection of documents associated with each other, so that's not a candidate.
I don't like Media because it isn't an image/video/audo.
Lloyd is correct about using Attachment directly, however, you could put it in DocumentReference.content.attachment.
So, in my mind, you're looking at Binary or DocumentReference. Or Binary AND DocumentReference -- sinceDocumentReference.content.attachment.url could point to something stored under Binary. If you use DocumentReference, I would suggest using Binary or some other place outside of the DocumentReference to store the content (i.e., don't use attachment.data), since there may be good use cases for retrieving the metadata separately from the document content.
Eric Haas (May 24 2017 at 23:50):
@Elliot Silver Why is media restricted to image/video/audio? seems arbitrary. Also depending on the context could point to Diagnostic Report or Observation. DocRef seems like a good choice to me.
Elliot Silver (May 25 2017 at 05:55):
@Eric Haas , well, the scope of the resource is "A photo, video, or audio recording acquired or used in healthcare. " and the mandatory element type is a code limited to audio, video, or photo. I don't think there's any intention of being able to put something like a PDF in there.
Nate Walker (May 25 2017 at 09:11):
I think this should support any media type - and PDF is included in this. One would assume any media could be passed with a format (application/pdf) and then processed as such. This way you then have futureproofing with things like STL files for 3d-printed braces as an example
Nate Walker (May 25 2017 at 09:14):
Actually, a binary would work for this. But then why do we have binary and media when media can be a subset of binary?
Lloyd McKenzie (May 25 2017 at 12:56):
Binary has no metadata beyond mime type. It's just intended to store the blob. Media is focused on the metadata. It can include the blob, but may just point to it. And the metadata Media has is focused on images and videos. DocumentReference serves a similar purpose for document-type blobs.
Tim Berezny (May 25 2017 at 13:35):
Thanks @Elliot Silver and @Lloyd McKenzie , thanks, that's a big help. For the purposes of sending a referral, the metadata requirements are pretty light I think. We probably want to preserve the filename, and perhaps some classifier about what kind of document it is (e.g., assessment report, consult request note, etc...).
Sounds like it's between /DocumentReference and /attachment (with a preference for using the URL instead of .data).
However, on the .url vs .data issue, practically speaking for eReferrals, a common use case would be to send from an EMR (particularly locally deployed client-based physician office solutions) that has no capability of providing a .url to reference to. i.e., it wants to send the referral off in one transaction and be done with it. In this case, is .data the way to go?
Reviewing /DocumentReference a bit more, it feels like overkill for referral purposes. I don't think i have any need for any of the "required" fields in that resource, i would likely just be filling those with placeholders.
Lloyd McKenzie (May 25 2017 at 14:52):
You can't use /attachment directly because it's a data type. You can only point to a resource. So you'd be looking at DocumentReference and populating the DocumentReference.content.attachment. If you want the content embedded, you'd use .data. If you think the requirements on DocumentReference are overkill, feel free to submit a change request. (I tend to agree, but I'm not an implementer of it, so my opinion has less weight :))
Elliot Silver (May 25 2017 at 16:12):
There are only a few required fields in DocumentReference: status, type, indexed, and content.attachment. I don't think that's overkill for your use case. Status is whether the document is current or not (in your case, I'd assume it is); you're already suggsting using the type to classify the document; and indexed is just when you added the document. All sound reasonable for your use case.
My preference for attachment.data vs attachment.url is just my preference; the standard allows either, so do what works best for you. However, I disagree with your reasoning about not having a usable URL. You can submit a Bundle containing the DocumentReference, and a Binary containg the document, and the attachment.url will point to the resulting Binary. This allows you to separate the data blob from the metadata.
Lloyd McKenzie (May 25 2017 at 16:27):
indexed is overkill. It's not needed, so we shouldn't force it to be present. I'm not sure if it's reasonable to mandate type all the time either. It doesn't seem to meet the use-case of "can't possibly do anything with the resource instance if this is unknown"
Elliot Silver (May 25 2017 at 16:29):
OK, that logic seems reasonable. I'll file a tracker. However, I don't think the current requirements get in the way of @Tim Berezny's use case.
Eric Haas (May 25 2017 at 16:33):
I think the issue is the DocumentReference is really confusing if you don't understand its context of XDS and IHE stuff I forced myself to read several times to begin to understand it all. Media is straight forward easy-peasy and adding documents to its scope could make that a whole lot easier too. But then we have multiple ways for doing the same stuff :-(
Lloyd McKenzie (May 25 2017 at 16:36):
I'd be happy if DocumentReference were clarified a bit to be less XDS-centric and to recognize its use as just a way of passing around wrapped documents and similar artifacts
Eric Haas (May 25 2017 at 16:41):
re "passing around wrapped documents and similar artifacts " to my earlier point what makes a pdf unique from a png or mpg and whatever else is out there or in the future. These boundaries are blurry
Elliot Silver (May 25 2017 at 16:43):
GF#13447 for min cardinality.
Lloyd McKenzie (May 25 2017 at 16:45):
Well, Media has metadata for image height and width. DocumentReference has metadata for document type. So they're definitely targeted to wrap different types of artifacts. Making the distinction and relationships clear in their intros would be a good idea though.
Eric Haas (May 25 2017 at 16:57):
OK picking on Lloyd again. We had conversions about Media being a type of Observation but DR not so much in my opinion.
Eric Haas (May 25 2017 at 16:59):
and to take it step further everywhere there is Media do we need to consider DR?
Tim Berezny (May 25 2017 at 17:14):
I'm looking here, https://www.hl7.org/fhir/documentreference.html and see the required fields for /DocumentReference as status, docstatus, relatesTo.code. And it says type is preferred not required, and no required marking on index. These are different than what @Elliot Silver mentioned, am I looking in the wrong spot?
My comments on the required fields in /DocumentReference, for the purpose of eReferral
1. Status: will always = "current". eReferrals are kind of transient by definition, it's not a repository. So it would be a pretty big stretch to think of a scenario where that gets ="superseded". I can conceive of it... but only mildly. I can include it, but realistically i would likely make it an optional field to my eReferral API.
2. docStatus: similarly to status, i will probably just always set it to "final", and make it optional to input to my eReferral API.
3. relatesTo.code: I don't understand this one or how it might be useful in an eReferral context. (Is this one of those XDS/IHE-ish types of fields you mention?)
Regarding Using a bundle for the URL reference: Right, ok, that makes sense. Thanks.
Lloyd McKenzie (May 25 2017 at 17:45):
By "required", we meant "minOccurs = 1".
Elliot Silver (May 25 2017 at 17:45):
@Tim Berezny I'm looking at the same place, but differ in how I read it. docStatus is 0..1, so it's optional; relatesTo.code is 1..1, but relatesTo is 0..*, so relatesTo.code is required only if relatesTo is present. type is 1..1 so it is required, but the vocabulary to use is not fixed -- there is only a recommendation.
I agree that in your case, you'll probably always use status=current.
Tim Berezny (May 25 2017 at 18:37):
Ooooh, I see. Thanks for that clarification. I've been looking for "required" in the description field, but i see now that that relates more to the valueset that is used with the variable.
Tim Berezny (May 26 2017 at 14:36):
Another question, would the "title" field in the attachment datatype be the right spot to put the original filename?
Lloyd McKenzie (May 26 2017 at 15:12):
It's more for the document name, not necessarily the file name.
Tim Berezny (May 26 2017 at 20:50):
Is there another spot allocated for the filename? I'm looking between attachment and documentReference and don't see a spot.
Lloyd McKenzie (May 27 2017 at 00:54):
Not yet. So far, there hasn't been a use-case for sharing it. What's the purpose?
Grahame Grieve (May 28 2017 at 20:29):
I usually put filename in the attachment title - if I have a filename, I usually don't have anything else to put in the title, and it's the most descriptive thing that there is
Grahame Grieve (May 28 2017 at 20:29):
and when I'm pulling something out of an attachment and looking for a filename, I convert the title to a valid filename (strip characters etc)
Tim Berezny (May 30 2017 at 20:59):
Good to know, thanks. I think i'll pursue that approach of putting filename into the title.
Last updated: Apr 12 2022 at 19:14 UTC
