Stream: implementers
Topic: photo, image, & Media
Abbie Watson (Jun 13 2017 at 15:27):
Has there been any thought given to harmonizing photos, images, and the Media resource? I'm seeing Patient.photo and BodySite.image as both being Attachments rather than Media. Doesn't it at least make sense to harmonize towards BodySite.photo or Patient.image? Also, I would have thought both Patient.photo and BodySite.image would be Media, rather than Attachment. Or is the thinking that we're specifically including the possibility of PDFs as "photos"?
Lloyd McKenzie (Jun 13 2017 at 15:34):
BodySite.image could be an xray or ultrasound image. Patient.photo would be a photograph only. Pointing to Media only makes sense if the element is typically treated as a stand-alone resource. That certainly wouldn't be the case for Patient.photo. Less sure about BodySite.image.
Alex Goel (Jun 13 2017 at 15:34):
I think that clinically relevant images like BodySite.Image may have different needs than Patient.photo. I think it might make sense to consolidate them, but they have different requirements and very different use cases in my opinion
Abbie Watson (Jun 13 2017 at 16:23):
I hear that. At the end of the day, though, the vast majority of DICOM images wind up being vanilla photos wrapped in a DICOM header.... photos defined by the Joint Photograph Experts Group as part of the standard, no less. So some of these different use cases wind up in the same place, and there's less variance that it first seems. I don't have any particular agenda here. I was implementing a very basic Digital Avatar utility and was working with the BodySite resource, and it just seemed weird that it wasn't harmonized with the other resources. Just giving a bit of feedback on a Maturity Level 1 resource.
Eric Haas (Jun 13 2017 at 16:34):
Yes the OO and Imaging workgroups have been looking at this and will be bringing this topic up with Infrastructure and MNM. The general consensus is that providing clear guidelines is between Media and Observation= valueAttachment is proving to be challenge. We are looking at several options on how to consolidate them or at least make sense of this.
Eric Haas (Jun 13 2017 at 16:35):
Your input is welcome.
Elliot Silver (Jun 13 2017 at 16:58):
I would also suggest that the X-ray or ultrasound image use cases shouldn't be handled by either an attachment or Media -- they should be handled by ImagingManifest (or potentially ImagingStudy), which is used to point to DICOM content.
If you're trying to reference DICOM imaging, and these don't work, the Imaging workgroup would like to hear about why.
Lloyd McKenzie (Jun 13 2017 at 18:08):
Well, if you're trying to identify a BodySite and want to include the xray or ultrasound that shows a particular fracture or tumor or whatever "inline", you might not want a separate resource.
Grahame Grieve (Jun 13 2017 at 22:41):
there's also the thing were supporting dicom formats is 100x more expensive than png or jpg
Elliot Silver (Jun 14 2017 at 00:07):
If you have an X-ray or US, it will start off in DICOM format. It seems appropriate to leave it in DICOM format, and to use one of the Imaging resources. If the imaging resources aren't appropriate, please provide feedback. I'd really discourage converting an image to jpeg and them putting the jpeg in an attachment, or making multiple copies of the DICOM image. Not only is this inefficient use of your FHIR server's storage, but it causes multiple lifecycle management issues. I'd much rather see references to the DICOM content.
I'd argue that DICOM is not more expensive than png or jpg. Storing information in a reliable manner, such that it can be found, retrieved and used years (or decades) later is more expensive than stuffing them in your sock drawer though.
Grahame Grieve (Jun 14 2017 at 00:45):
Dicom won't be more expensive than PNG or JPG when there is free libraries in all the main devlopment frameworks , and when the browsers support it natively
Grahame Grieve (Jun 14 2017 at 00:45):
it's also possible to store pngs or jpegs properly.
Grahame Grieve (Jun 14 2017 at 00:46):
I'm not saying that there's no value in DICOM, or good reasons why the support I just mentioned doesn't exist. Just that it's stupid to ignore the fact that it doesn't exist
Grahame Grieve (Jun 14 2017 at 00:47):
and already, it is routine practice to thumbnail DICOM images to PDF, PNG or JPG and redistribute them on other channels. particularly to the patient. And it's futile to try to and change that
Grahame Grieve (Jun 14 2017 at 00:49):
I would've thought that the deployment difference between data that can be displayed on any platform with no external dependencies vs data that needs a server - and access control - was pretty obvious.
Grahame Grieve (Jun 14 2017 at 00:50):
so that means, converting to a media resource. I don't think that II is served by trying to push the rock uphill on this
Abbie Watson (Jun 14 2017 at 19:44):
Here's a thought.... why doesn't Media have a 'url' field?
John Moehrke (Jun 14 2017 at 19:45):
It does... Media.content.url
Abbie Watson (Jun 14 2017 at 19:48):
Ah. Hmmm.... interesting. Need to give this some more thought then.
Eric Haas (Jun 14 2017 at 20:33):
The attachment type contains all the juicy bits. Everything else in Media is clinical context and additional metadata ( height, width, duration, etc)
Last updated: Apr 12 2022 at 19:14 UTC
