FHIR Chat · Imaging Needs · media issue

Stream: media issue

Topic: Imaging Needs


view this post on Zulip Elliot Silver (Oct 06 2017 at 22:32):

Here are some of the concerns that I'd like to see addressed.
1. We already have a resource to describe the contents of a full DICOM imaging study. ImagingStudy follows the Event prototype, and in many ways, mirrors Observation. The resource lists the contents of the DICOM study, and includes the information needed to retrieve the images from a PACS or other image archive. The actual images aren't stored in FHIR. I don't see the outcome of this discussion will impact that resource significantly.
2. I see a need to capture the clinical context of other non-DICOM imaging (pathology, dermatology, wound care), video (endoscopy, surgery), potentially ECG and audio waveforms.
3. I see a need to include “images of interest” in reports, etc. These may be JPEG renderings of DICOM images, selected regions of interest on an image (or a trimmed audio or video clip), an annotated image, etc. It should be possible to link derived media back to the source media or DICOM image.
4. It should be possible to link derived observations back to the source media or DICOM image.
5. To cover patient-supplied photos, etc. there should be low metadata requirements on the media content. It should also be possible to have media (with as much context as possible) in the absence of it being used in a report, or referenced by an observation, etc. (Open question is whether clinical media needs to be tied to an encounter or procedure.)
6. Consider whether we need to support media with multiple “subjects” (a group photo of HL7 WGM attendees who have subsequently come down with a mysterious disease; an audio recording of a group counselling session).
7. We should review all references to Observation, Media, DocumentReference, ImagingStudy to see if we need to allow other resources.
@Brad Genereaux Any thoughts about what other success criteria should be?

view this post on Zulip Eric Haas (Oct 06 2017 at 22:55):

second bullet = Media Option 2 with some edits
third bullet = Media Option 2 wtith some edits
fourth bullet = Obs.element = type ref(Media) Option 2
fifth bullet = Attachment data type as is plus /minus height/width/frames/duration
sixth bullet = Media.subject (Group)? - already there
seventh bullet = ?? (this is part of normal QA process)

view this post on Zulip Elliot Silver (Oct 06 2017 at 23:05):

For #5, I was still thinking about "clinical multimedia" -- patient supplied wound photos, etc. If we go with "Option 2", I think they would be captured with Media, but we need to make sure that it most content is optional.

view this post on Zulip Eric Haas (Oct 06 2017 at 23:07):

Agree and In Base standard very little if anything is Min = 1.

view this post on Zulip Elliot Silver (Oct 06 2017 at 23:10):

True.
I was trying to lay out how could we judge if whatever we decide on works. I've done similar efforts before, and you get to the end and realize that you forgot that one use case that invalidates the whole solution.

view this post on Zulip Eric Haas (Oct 06 2017 at 23:28):

.. as long as we are shooting for the 80%...


Last updated: Apr 12 2022 at 19:14 UTC