ImagingStudy, ImagingManifest, and ImagingObjectSelection

Hi all!

I’m wondering if anyone can explain why ImagingObjectSelection was removed in FHIR v3? This would have been supremely useful for getting images flagged for specific purposes from a PACS, such as inclusion in reports, quality improvement, etc. The specification now points toward using ImagingManifest instead. However, ImagingManfiest has removed the frame property from its instances so you can longer reference a Frame Number.

In short, for a project we are working on how, we need to use native DICOM because FHIR v3 can’t seem to properly support Key Object Selections or frame number references. We actually had a FHIR v2 solution designed and had to change it to use a combination of v3 and DICOM’s WADO.

My hope is that, by asking the group, I will learn about the rationale for this, or even learn of a different way to implement DICOM Key Object Selections using FHIR v3.


Hi Pete,

ImagingObjectSelection evolved into ImagingManifest.

ImagingObjectSelection was tightly modelled on a DICOM Key Object Selection file, and certain uses of a KOS don’t translate well to use in FHIR. In particular, it was possible to express something like an IOCM KOS, which intends to suppress availability of content, using ImagingObjectSelection. Those uses don’t seem to make sense in a FHIR context.

On the other hand, the primary use we heard about for ImagingObjectSelection was IHE RAD’s desire for a FHIR equivalent of the XDS-I Image Manifest KOS.

Therefore, ImagingObjectSelection was renamed to discourage people from thinking that it was a complete FHIR replacement for a general DICOM KOS. Instead we wanted to suggest that it was a positive statement of included images, like the XDS-I Image Manifest.

That takes care of the “where did ImagingObjectSelection go?” part of your question. The other part is, “what happend to frames?”

Part of this is related to the key use case of supporting XDS-I, which doesn’t usually include frame-level information. It was also due to trying to simplify the resource, and evaluating it against FHIR’s 80% rule (only include core elements that 80% of the systems need). Finally, we are trying to walk a line between duplicating DICOM capabilities and making imaging information available to non-imaging systems. For all these reasons, we felt that frame-level information wasn’t needed in ImagingManifest.

If I recall, the discussion at the time was that we would define a standard extension to convey frame information. However, we never go around to this before the STU3 cutoff, and I see that we didn’t submit a tracker item to ensure it gets done in the future.

Interestingly, I see someone has filed a tracker item concerned that frames were removed from STU3.

There are typically only a small number of people on our T-cons and at the working group meetings. With wider participation from people like you and the submitter of the tracker item, we could do a better job of ensuring all needs were addressed.

If you are using STU3, my suggestion is to define your own extension to convey frames. If the Imaging Integration WG does pursue the extension route, switching from your extension, to the standard extension would probably be fairly easy. Or if the committee concensus is that we erred in removing frames, it could be restored to the resource as part of the FHIR release 4 process; keep an eye on to see the most recent changes.

Alternatively, depending on why you are conveying frame-level information, I suggest you look at the Media resource. It would be the appropriate way to convey the WADO URL for a rendering of a specific frame.


Thanks for your reply, Elliot. The switch to ImagingManifest makes a lot of sense with this background. That part itself would still work for our use case.

I have not worked much with DICOM, but on this project it seems that frame numbers are quite important. They were obviously important enough to include in v2.

The WADO endpoints included in ImagingStudy could help, but it appears that they aren’t meant to specify “sub-resources” including frames. (The WADO syntax supports this, but FHIR the FHIR endpoint address only “identifies the HTTP(S) service base url. That is, only the scheme, authority and path are included. Neither a quetstion mark (?) nor any query parameters shall be included,” so we can’t stuff that in the endpoint URI.

It seems that FHIR is deferring to WADO-RS and WADO-URI, which does make sense, except that WADO does not really support Key Object Selections in a web-friendly way.

I think you are right that defining a frames extension or using the Media resource is the way to go. Unfortunately for now, we’ve had to use a multi-step process that goes like this:

  1. Request FHIR ImagingStudy. Identify that a KOS exists by looking for a series identified with
  2. Request every KOS from the ImagingStudy using WADO and parse the native DICOM, in order to find the appropriate KOS by title and date.
  3. Extract UIDs and Frames from the appropriate KOS.
  4. Find those UIDs in the FHIR ImagingStudy in order to get their Series and Study UIDs.
  5. Make WADO-URI calls for the individual rendered images using Series UID, Study UID, Instance UID, and Frame.

Whew! With that in mind, you can see how a simple FHIR resource that represents a selection of images and includes all the information necessary to request that image from a WADO server would be helpful.

Thanks again, and I hope this feedback is helpful.


Hi Pete,

First off, please add your use case as follow-up to the tracker item I mentioned ( It would also be helpful if you could include a justification for why this is needed/belongs in FHIR, rather than defer to DICOM capabilities (which as you point out, do provide a means to accomplish what you need).

The WADO Endpoints in ImagingStudy and ImagingManifest were defined to be the base URL, with the view that you could combine that URL with the study, series, and instance UIDs in the resource to create the URL you needed. Obviously, if you want frame-level URLs, that falls down without frame-level information. However, if you had frame numbers (via, for example, an extension), WADO endpoints in the resource would be the basis for creating the frame-level URLs.

I think your multi-step process is (just) a little more complicated than it needs to be. The KOS will include the Study and Series UIDs, so there is no need to look those up in the ImagingStudy again once you have the instance UID.

On the other hand, if you think this suddenly gets simpler if ImagingManifest supported frames (or could be included via an extension), don’t forget that someone would still need to generate the ImagingManifests from the KOS instances. That might not be you, but it will be an additional step that will need to be performed.

(As an aside, because we want the ImagingManifests to only be a statement of “here’s content we want to share”, there is no longer a coded title element, only a text description. You are apparently using the KOS title to select which KOS to use. If ImagingManifests are only created for “positive” KOS, do you still need to distinguish why they are being shared? Is the distinction between “best in set” and “for sharing” important? Obviously, there is some information which is not carried over, but for, for example, an EMR’s FHIR use, as opposed to a PACS’ DICOM use, is this significant? Or, is this the point at which we say, “yup, you’ll need to use DICOM for that.” If you have thoughts on that, please let me know.)


OK. I can add this to the tracker.

I can see why you might think the DICOM KOS has the Series UID, as I did originally. However (and realize I am new to DICOM) the KOS is itself a series, with the modality of KO. The KO series includes references to actual instances which really belong to another series, such as an ultrasound. When you ask WADO for the image, you include that instance’s proper Series UID, the series from where it originates. So there is a need to merge info from the KOS and ImagingStudy. Not a huge deal, but it would be better if the KOS included all the identifiers required to retrieve the image from WADO (or if a FHIR equivalent did).

someone would still need to generate the ImagingManifests from the KOS instances

Point taken, and it may be that I’m asking FHIR to fix shortcomings in WADO. However, if the goal is to allow non-imaging systems to easily access images, and if KOS and frames are common (not sure), then I think this is too convoluted and should be fixed either in FHIR or WADO.

do you still need to distinguish why they are being shared?

Apparently, yes. There may be many KOS and they are being shared for different purposes. Slides for a conference, quality reviews, for inclusion in reports (our use-case), and others.

Thanks again,