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 build.fhir.org 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.
Elliot.