Stream: implementers
Topic: ImagingManifest - is it needed?
Brad Genereaux (Sep 10 2017 at 11:03):
This question was posed in the II mailing list - wanted to raise the question here, too -
One of the topics that came up in the last II conference call was whether ImagingManifest (http://hl7.org/fhir/imagingmanifest.html, maturity level 1) should be removed from the FHIR specification. In recent months, the IHE Radiology profile that defined its main use, MHD-I (Mobile access to Health Documents for Imaging - https://www.ihe.net/uploadedFiles/Documents/Radiology/IHE_RAD_Suppl_MHDI.pdf), has been under discussion and active revision, and has even undergone a name change to become WIA (Web Image Access), using only DICOMweb resources.
Prior to becoming ImagingManifest, the FHIR object was called ImagingObjectSelection, which essentially represented a DICOM Key Object Selection (KOS) document, which created its own set of confusion by replicating the functionality as the DICOM object with a variety of open-ended problems. We then constrained the object to represent Manifests, like those used in MHD-I - but with MHD-I no longer making use of them, those on the last call felt it would be prudent to discuss removing the resource altogether.
One of the topics we'd like to explore during the September WGM II meetings is, whether ImagingManifest can be removed (with ImagingStudy remaining unchanged), and what outstanding concerns are there from implementers.
Grahame Grieve (Sep 10 2017 at 16:06):
I've never really understood the difference
Grahame Grieve (Sep 10 2017 at 16:07):
and discussions with implemeters suggest "ImagingReferences' as a name that some would find clearer
Elliot Silver (Sep 10 2017 at 17:39):
The difference between ImagingStudy and ImagingManifest is that IS lists all images in a single DICOM study; IM lists selected images, potentially across multiple studies. One advertises everything that is available, the other highlights instances of interest. There is expected (but not required) to be one IS per DICOM study, but may be many IMs, e.g. reflecting different selections. The difference between the old ImagingObjectSelection and the new IM is that IOS very closely followed the DICOM Key Object Selection definition, that is used for a variety of things, including flagging key images, XDS-I, and conveying between imaging servers lists of images to be deleted; IM doesn't follow the KOS structure quite as closely, and is scoped to exclude the deletion case.
The question Brad raises is that if we have excluded the deletion case, and IHE is pursuing another approach for MHD-I that doesn't use IM at all, is there value in still having IM to only list selected images? In the environments where FHIR will be used, would it be just as easy to link to the selected images from Media or something similar?
Grahame Grieve (Sep 10 2017 at 17:46):
I never thought have different structures for this is useful... should be done as a flag on the same structure, surly
Elliot Silver (Sep 10 2017 at 17:54):
IS is restricted to exactly a single study, and contains descriptive elements of the study. IM can reference content from multiple studies, and contains descriptive elements about the selection. The thought was that these were such distinct uses that separate resources made sense.
John Moehrke (Sep 10 2017 at 21:28):
The distinction is not that important to the non-imaging consuming application. They just want to navigate to interesting things. I could see a ImagingReference that might be pointing at exactly one Study, and might hold all images in that study; or might be equivalent to a KOS and thus pointing at many studies with only selected images. The navigation by an app would be the same.
John Moehrke (Sep 10 2017 at 21:31):
I would still advocate that this target app should not need to understand DICOM to be useful. ANy application that understands DICOM might find minimal value, needing only identifiers. So we either intend to help non DICOM applications, or we might just continue to just use the assession number.
Brad Genereaux (Sep 11 2017 at 22:09):
It would be helpful to get the input of consumers -- because, as a provider of ImagingStudies, I would rather produce a bundle of ImagingStudys which gives enough information to an EMR or other consuming application all the information they need to safely display information (like, what was the procedure/order why the imaging was generated; where is the report or observations that are derived from the images) along with a way to dig deeper to grab the imaging or start a viewer with a Study UID. It can tell the whole story with context and traceability. ImagingManifest today provides hardly anything of any value to a downstream system - just a grabbag of identifiers and an optional reference to the imaging study. My strong preference is to eliminate ImagingManifest and (if needed) adjust ImagingStudy accordingly if it doesn't do anything desirable that ImagingManifest can do. The only thing I can think of is ImagingManifest can reference multiple studies - but this can easily be done with ImagingStudy by just returning an array list of ImagingStudies.
Grahame Grieve (Oct 05 2017 at 00:27):
ImagingManifest can be a subset. As long as ImagingStudy can only reference a subset of the study, I think it makes sense
Last updated: Apr 12 2022 at 19:14 UTC
