Enhanced Image Metadata Query - Brief Proposal

From IHE Wiki
Revision as of 09:17, 12 September 2011 by Kho (talk | contribs) (Created page with "__NOTOC__ ==1. Proposed Workitem: Enhanced Image Metadata Query== * Proposal Editor: Kinson Ho * Editor: Kinson Ho * Date: N/A (Wiki keeps history) * Version: N/A (Wiki keep...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search


1. Proposed Workitem: Enhanced Image Metadata Query

  • Proposal Editor: Kinson Ho
  • Editor: Kinson Ho
  • Date: N/A (Wiki keeps history)
  • Version: N/A (Wiki keeps history)
  • Domain: Radiology

2. The Problem

With many advanced modality and imaging protocol today, the need for an Image Display to access the (nearly) full header information for proper displaying the study becomes increasing important. The Query Image transaction is designed to only provide basic information for the Image Display, but not enough for properly identify hanging protocol or determine the sequence of images to download for efficient display. So there is a need to enhance the ability to query for image metadata.

This problem becomes even more important for cross enterprise access of imaging information because of the longer latency for image access. So the identified solution should be able to support DICOM query as well as XDS Stored Query.

3. Key Use Case

Local Image Display use case Before Image Display retrieves the images, it tries to determine the proper hanging protocol for the study. The Image Display queries the Image Manager for full metadata (patient, study, series and instances level). Given the hanging protocol defined, then the Image Display can determine what images to retrieve first for efficient display of the study.

Cross-enterprise on-demand use case Similar to the local Image Display use case, but the study is identified in another enterprise via XDS-I or XCA-I. The Cross Enterprise Access use case makes the problem more challenging because for XDS-I and XCA-I, currently there is an additional manifest that needs to be first retrieved to identify the study before able to retrieve the metadata. Therefore this will impact the effectively of the on-demand display use case.

4. Standards and Systems

XDS-I, XCA-I, DICOM C-Find, DICOM enhanced multiframe SOP class conversion, DICOM No Pixel Data Transfer Syntax, IOCM

Potentially work together with the XDS-I Registry Metadata Extension proposal

5. Discussion

For the query perspective, there are a number of possibilities to provide richer metadata access:

  • Use DICOM No Pixel Data Transfer Syntax to retrieve the study without the pixel data first
    • Pros: Already defined in DICOM
    • Cons: A two step process, first query for what study is available, and then retrieve just metadata. This becomes a three-steps process for XDS-I because it needs to retrieve the manifest first to identify the study
  • For large study (e.g. CT, MR, etc.), define a standardized conversion of old single frame to the enhanced multiframe sop class, then use DICOM No Pixel Data Transfer Syntax to retrieve it
  • Define a special study description (e.g. FULL_METADATA) and the Image Display can query on this study description using DICOM C-Find / C-Move and the Image Manager can generate a transient sop instance with full metadata and returned.

IHE is a good venue to solve this problem because this becomes a common problem with the improvement in advanced imaging and so far different vendors have different proprietary mechanisms. This makes cross vendor interoperability suffer and fall back to basic technique which is not efficient.

Furthermore, as cross enterprise access becomes more widely adopted, the XDS-I and XCA-I model becomes a significant bottleneck for efficient image display for on-demand use cases.

Risk:

  • Need to come up with a mechanism that make use of existing standards that can efficiently address the problem. There are many potential candidates but no clear solution.
  • Metadata synchronization must be taken care of if a separate SOP instance is used to collect metadata. A study may be split / merge using IOCM.